On 9 December 2017 at 23:47, Steve Langasek <steve.langasek@ubuntu.com> wrote:
> Furthermore, that this really does not answer the original question. I
> find it quite possible that the question will still stand regardless of
> whether or not I considered a snap. This is a build-level issue, from
> what I can tell, not necessarily a matter of the packaging framework.
> That said, do you have any relevant advice?
Well, except that you don't have to backport the stack package-by-package
onto trusty in the case of a snap, you could simply use all of the
already-successfully-built .debs from zesty as needed; so I would expect
this to be a non-issue for a snap.
It's not quite as easy as just using the Zesty debs when building your snap, because the Zesty user-land is built against a newer libc than that included in the core snap, which is currently the only base snap available based on Ubuntu, and is built against the Xenial user-land. The fact that the debs from Zesty will be compiled against the newer libc means that they are likely unable to run on the libc included in the core snap and you'll still have a problem with having to backport in some sense. The error you'll get if you do use the Zesty repositories is similar to "python3: /lib/x86_64-linux-gnu/libc.so.6: version 'GLIBC_2.25' not found (required by python3)".
My preferred way to build a user facing application for distribution via snappy, that is an application which requires newer dependencies than available in the Xenial repositories, is to include each dependency as a separate part in the snapcraft.yaml used to build the snap. See for example the way I added newer fontconfig and freetype support to the Corebird snap, which allowed me to enable the colour emoji support, and added an updated gstreamer, which allowed me to provide users with a fully licensed h264 library from cisco.
The advantage of building dependencies into a snap rather than tackling the back-porting process for inclusion in the backports repository is that you do not need to be tightly bound by any historical requirements or common practices if you don't want to, and don't need to worry about trampling on someone else's environment. By eschewing the historic and common methods you can, if you desire, e.g. rearrange the file-system within your snap ignoring the FHS, or include dependencies that aren't available in any repository, or change a dependency unilaterally; all without worrying about breaking the world of other installed packages.
--
Daniel Llewellyn
Bowl Hat
