Inspecting package differences across core/base snaps

[ogra]

in preparation of providing base snaps for different distros I propose we require the same set of binaries on all distros. i imagine not all packages we use in ubuntus core snap will not be identically available in all distros but have different names or might not even be available.
as a start it might help to compare the packages from https://code.launchpad.net/~snappy-dev/+snap/core/+build/34401/+files/core_16-2_amd64.manifest (which is the list of binary debs inside todays core snap package) with other distros.

[zyga]

This is an interesting concept but I don’t think it is something we actually want to do. The base snaps should allow you to precisely make a base snap that doesn’t have any things you don’t want. You can also place them in different locations (e.g. libexec).

What I’m really saying is that the base apparmor template or interfaces are really talking about files in the ubuntu-16 base snap. We need to think about how they behave (for those that care) on other base snaps. I suspect that the very same interface will give different permissions when the consuming snap is using a particular base vs another base, simply because this will allow us to change interfaces around by the time we get ubuntu-18 base.

[ogra]

well, you need to roll some kind of “rootfs” using the respective tools for the respective distro and that will want a package list …
undoubtly there will be differences and undoubtly we need to add extra bits and perhaps rip out ubuntu-isms (i.e. apparmor interfaces as you mentioned them), but to provide a similar functionallity on all distros we will also need a kind-of similar list of installed binaries. what i want here is to first get a list of all packages for all teh distros we want to support …
then we can go though them and prioritize if they are providing something essential or not and weed out stuff you might not need on other distros.

[Conan_Kudo]

in preparation of providing base snaps for different distros we will require the same set of binaries on all distros. i imagine not all packages we use in ubuntus core snap will not be identically available in all distros but have different names or might not even be available.
as a start it might help to compare the packages from https://code.launchpad.net/~snappy-dev/+snap/core/+build/34401/+files/core_16-2_amd64.manifest (which is the list of binary debs inside todays core snap package) with other distros.

At a glance, I see a few issues for most distros:

• Requirement of initramfs-tools instead of dracut. Unlike initramfs-tools, dracut is supported on every distribution family (including Debian/Ubuntu!). Requiring initramfs-tools instead of dracut will make things hard for alternative full-snap systems.
• Inclusion of cgmanager (most distros generally use systemd for cgroup stuff)
• The ubuntu-core-* packages (I’m not sure what’s in them, so it may or may not be possible to make variants of them)

Fedora specifically has the additional problem of not have apparmor packaged in the distribution.

This is an interesting concept but I don’t think it is something we actually want to do. The base snaps should allow you to precisely make a base snap that doesn’t have any things you don’t want. You can also place them in different locations (e.g. libexec).

What I’m really saying is that the base apparmor template or interfaces are really talking about files in the ubuntu-16 base snap. We need to think about how they behave (for those that care) on other base snaps. I suspect that the very same interface will give different permissions when the consuming snap is using a particular base vs another base, simply because this will allow us to change interfaces around by the time we get ubuntu-18 base.

Please don’t say things like this. I definitely want to be able to produce an all-Fedora system using snaps. It would line up well with the Fedora Modularity project.

There’s literally no reason to not allow the construction of alternative core snaps with with supporting different base snaps.

[ogra]

Requirement of initramfs-tools instead of dracut. Unlike initramfs-tools, dracut is supported on every distribution family (including Debian/Ubuntu!). Requiring initramfs-tools instead of dracut will make things hard for alternative full-snap systems.

i’d leave that bit to the respective distros to re-implement the scripting in a dracut created initrd … while teh dracut tool is available in ubuntu and debian it is not used nor being tested afaik … for now i’d focus only on the base snap as environment for execution of the distro specific snap packages, i think making a bootable all-snap image is up to the distros themselves as a later step. the initramfs creation bits do not need to live inside the core snap (only the resulting initrd.img needs to be available for the snapcraft kernel plugin). feel free to just ignore that bit.

[ogra]

since the question came up: https://github.com/snapcore/core-build holds the ubuntu-core-config package source, additionally there are hook scripts used by live-build in https://github.com/snapcore/core that mangle the filesystem before it gets snapped up (like removing all non-snap package managers etc). the ubuntu-core package itself just represents the content of the manifest file i initially linked (its just a meta package) likewise the ubuntu-core-libs package … for both of these you would need to use the seed mechanism of your distro to get the package list into the build.

[Conan_Kudo]

while teh dracut tool is available in ubuntu and debian it is not used nor being tested afaik

Actually, Debian has been testing it for the last few years. There’s been a slow-burning effort to get all the pieces in place to replace initramfs-tools with dracut in Debian. I’ve even built Ubuntu systems using dracut that work perfectly fine. It’s really just a matter of pushing for the final bits to be in place.

For reference:

• http://penta.debconf.org/dc13_schedule/events/961.en.html
• https://www.youtube.com/watch?v=csXYf298z34
• https://summit.debconf.org/debconf15/meeting/378/breaking-your-machine-with-dracut-workshop/
• https://debconf16.debconf.org/talks/127/
• http://blog.tenstral.net/2017/04/on-tanglu.html

[zyga]

There’s literally no reason to not allow the construction of alternative core snaps with with supporting different base snaps.

You are totally missing the point. The roles of core and base snaps are that the core snap provides snapd while the base snap provides the rootfs. You can create any base snap you want.

[ogra]

It’s really just a matter of pushing for the final bits to be in place.

but that is totally beyond the scope here … we’ll keep on using whatever our distro defaults to, else we’d have to maintain the delta as well as the tool itself …
if ubuntu or debian ever switch to dracut we’ll adjust for it, but for now i dont see that happeneing … and as i said above, i’m not after a bootable rootfs in the first place but after an execution environment for snaps … anything beyond this is up to the respective distros …

[niemeyer]

in preparation of providing base snaps for different distros we will require the same set of binaries on all distros. i imagine not all packages we use in ubuntus core snap will not be identically available in all distros but have different names or might not even be available.

@ogra Please update your post (UPDATE: I went ahead and did that, see the diff) so it doesn’t sound like an agreement that was made. This should be a question or a proposal instead, and the answer is likely “no” per @zyga’s note above. The whole point of base snaps is giving freedom to people (distributions or otherwise) to create a root filesystem (the “base”) that does not look like the default one.

What I’m really saying is that the base apparmor template or interfaces are really talking about files in the ubuntu-16 base snap. We need to think about how they behave (for those that care) on other base snaps. I suspect that the very same interface will give different permissions when the consuming snap is using a particular base vs another base, simply because this will allow us to change interfaces around by the time we get ubuntu-18 base.

@zyga I don’t see why that’d be the case. We should instead unblock the use of the base, but the details relative to the external world of the snap, which is really what interfaces are about, should not change.

[ogra]

The whole point of base snaps is giving freedom to people (distributions or otherwise) to create a root filesystem (the “base”) that does not look like the default one.

hmm, i understood the target is to support snaps built on $distro to actually run with their own core/base snap, would that not entitle to have snapd functional inside that core/base snap and have it have a similar set of features ?

the thread was simply supposed to collect info about the differences as a preparation work for the future discussion, i didnt mean to make it appear like anything agreed upon.

[ogra]

i updated the topic subject to hopefully make the target clearer.

[zyga]

@zyga I don’t see why that’d be the case. We should instead unblock the use of the base, but the details relative to the external world of the snap, which is really what interfaces are about, should not change.

I mostly agree but there are some details that bleed through, e.g. the location of certain executables that are encoded in the apparmor profile. Conceptually though, when ubuntu-18 is around we may want to stop supporting certain interfaces but still support them for snaps that use 16 as base.

[pedronis]

as I understood things snapd and a few related things would indeed come from the core snap which is then distinct from base with the full root and there would be only one snap providing snapd

[ogra]

so the base snap would be an additional exec environment sitting on top ?

[niemeyer]

the thread was simply supposed to collect info about the differences as a preparation work for the future discussion, i didnt mean to make it appear like anything agreed upon.

Even if not intended, your wording clearly indicated otherwise (“we will require”).

hmm, i understood the target is to support snaps built on $distro to actually run with their own core/base snap, would that not entitle to have snapd functional inside that core/base snap and have it have a similar set of features ?

The primary goal of base snaps is precisely to support divergences, because things will be different across distributions and even across releases of the same distribution. Requiring a matching set of binaries disagrees with that goal.

[ogra]

Requiring a matching set of binaries disagrees with that goal.

is there any completely written down plan about base snaps ? some kind of semi detailed spec ?

[mvo]

The idea around base snaps is slightly different, it seems like there is a bit of a misconception here. Probably best to add a new topic to outline the idea about the base snaps a bit more, I will go ahead and link from here once there is something to look at.

[mvo]

I outlined the core ideas in Introducing base snaps