ubuntu-app-platform updated to Qt 5.6.2

[Olivier Tilloy]

On Tue, Jan 31, 2017 at 2:12 PM, Timo Jyrinki <timo.jyrinki at gmail.com> wrote:
> 2017-01-31 10:23 GMT+02:00 Alberto Mardegan <alberto.mardegan at canonical.com>:
>> Do we have a clear understanding of why this happens? Qt apps are
>> supposed to be binary compatible against newer releases.
>> One exception could be if the app itself is shipping some plugins,
>> because in that case I believe that these plugins are somehow bound to a
>> specific Qt version.
>
> Yes, it seems snaps like ubuntu-terminal-app and dekko ship their on
> Qt version which should not be the case when the platform snap is
> used.

This is a bit tricky: when packaging a Qt application that uses the
platform snap, snapcraft will use ldd to crawl the app’s binaries and
will automagically add the libraries that it depends on to the
resulting snap (those libs are taken from the host system).

There is a way around that, but it’s rather counter-intuitive and
error-prone: add the packages containing those libs to the list of
stage-packages, then explicitly exclude them from the resulting snap
using the prime/snap keyword. You won’t be able to exclude them if you
didn’t include them through the stage packages first.

This is what we do in the webbrowser-app snap, and it works well
(proof is that this Qt update didn’t break it), but it makes
packagers’ lives unnecessarily complicated.

What can we do to make it easy for snap packagers to use the platform
snap with their Qt app? Add some logic to snapcraft so that it becomes
aware of the contents of the platform snap, maybe?

Cheers,

 Olivier


> Qt detects loading of modules with different versions and throws the
> error message. Technically we could patch Qt to not do this maybe over
> enthusiastic detection (Qt 5.6 point releases should naturally be 100%
> forward and backward compatible sans fixed bugs), but then again it's
> good that we detected these extra libraries being shipped.
>
>> And I wonder, maybe we should think of a different versioning scheme for
>> the interface? Otherwise, we should have a documentation page which maps
>> the snap version numbers to the Qt version contained within them.
>
> I think it's ok for now to keep the version "1" in the content field
> and not introduce a new package version or a package rename. I
> understood there are new features in development that could allow
> multiple releases to be available from the store at the same time, and
> maybe that would mean that package requiring content:
> ubuntu-app-platform1 could continue to get the last one with that
> version while developers could move to ubuntu-app-platform2 when such
> is decided to be released eventually.
>
>> Given that Qt is at the core of ubuntu-app-platform and that a change of
>> the Qt version is something we want all developers to be aware of, maybe
>> the snap (and the "content" interface field) should contain also an
>> indication of the Qt version they provide?
>
> The platform snap's description does contain the version of Qt
> included. However, the snap also contains lots of other libraries and
> more transparency would be useful. Certainly some documentation will
> be needed.
>
> -Timo
>
> --
> Snapcraft mailing list
> Snapcraft at lists.snapcraft.io
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft