Snapcraft snap doesn't exclude any libs from snaps it builds

Snapcraft maintains a list of libraries that are contained in the core snap. The purpose of this list is so that it knows what it can exclude from the snaps it builds when crawling for libraries on the system. There are a number of issues surrounding this, and I just noticed one more: Snapcraft uses platform.linux_distribution() in order to determine the release on which it is building, and then uses that information to determine the core snap library set to use. There are two problems here:

  1. platform.linux_distribution() is deprecated, and will be removed in Python v3.7
  2. Ubuntu distro-patches platform.linux_distribution() to return Ubuntu as opposed to Debian

Problem (1) means we should probably move away from this before too long. Problem (2) means that, since the snap builds its own Python (that doesn’t include the distro-patch) the snap thinks it’s running on Debian, which doesn’t match up with the core snap library list, so nothing gets excluded:

$ snapcraft
No libraries to exclude from this release

Perhaps the short-term solution is to apply the distro-patch to the Python being built in the snap, but we should consider alternatives to platform.linux_distribution().

1 Like

We should just remove this (for when a snap at least) and have people add their required stage-packages so its use is as intended.

That will require a lot more filtering used by developers to strip stuff out of their snap (pulled in by their stage-packages). How will they learn what’s contained in the core snap, and thus what could/should be stripped out?

Well, there is a forum post discussing this already (or was it mailing list email?). Regardless, that was the agreement we had.

Ah, you’re right-- this is a filter to be used when ldd crawling. By removing that feature this becomes a non-issue. Removing that from the snap and not the deb means they behave differently though, that sounds challenging to support.

It does, as much as a 2.0/3.0 line would. This should be 3.0 material.

Agreed. Should we apply the distro patch for now to keep things consistent, then?

@niemeyer what do you think about this? Should we keep things consistent for now? Perhaps it’s also time to start a v3 track, we’d like your thoughts on that as well.

1 Like

How about using lsb_release -i instead of the deprecated API?

I believe I fixed this on Monday with snapcore/snapcraft#1527. It needed to be changed for this to work correctly for non-Ubuntu systems, and the existing checks didn’t work at all for RPM based distributions.

The usage of /etc/os-release also allows us to start being able to identify distributions as families (using the ID_LIKE field in os-release(5). That will make it easier to handle derivatives rather than having to deal with identifying each and every distribution.

We’re not currently doing this, but it will be necessary for when we start supporting RPM based distributions, as the families are broader but still somewhat related.


Excellent, thanks @Conan_Kudo :slight_smile: . I’ll give it a test shortly and verify that this is no longer a concern.

1 Like

No go, guys:

$ snap list
Name       Version             Rev   Developer  Notes
core       16-2.27.5           2774  canonical  core
snapcraft  2.33+git58.67089e0  489   canonical  classic
$ snapcraft -d
No libraries to exclude from this release

That message indicates that something is still wrong, here.

@Conan_Kudo you got us most of the way there, I very much appreciate it. Turns out we actually had another bug that prevented your change from fixing this issue. With this PR and some good testing, Snapcraft can go to stable with my blessing:

1 Like