need help resolving python-setuptools backport fail

[Daniel Llewellyn]

On 9 December 2017 at 23:47, Steve Langasek <steve.langasek at 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.

Corebird ref:
https://github.com/snapcrafters/corebird/blob/master/snap/snapcraft.yaml

-- 
Daniel Llewellyn
Bowl Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20171210/0cdb2bfd/attachment.html>