Updates to snapd package on Arch

Hey

With the release of 2.26.14 and the imminent release of 2.27 we should look at updating distribution packages. I would like to see what can be done about the Arch Linux package, given how simple it is to maintain and build.

Currently Arch ships 2.26.1, I think we may need to update the package slightly though (I don’t think all the new features were packaged, like tab completion). I will update packaging locally on my Arch system, test it and then propose a pull request to merge the packaging into snapd master. Once we have packaging in master we can look at spread-testing Arch automatically. This should also give us a nice baseline to work with the distribution maintainers as we can always point them to the packaging we maintain and encourage them to pull from it as well as to contribute any changes they require back. The advantage of keeping a copy of the packaging in snapd is that we can always test against this and anyone working on snapd can change it.

I’ll reach out to Timothy Redaelli, who maintains the package, and let him know of my plans.

2 Likes

Thanks @zyga-snapd for this.

I would love to see someone in the community sign up for Arch maintenance because, as you say, it’s an easy package to dip your toe in with.

So I managed to fix my Arch installation (woot) and I’m working on package update to 2.26.14.

I proposed the current (old) Arch packaging in https://github.com/snapcore/snapd/pull/3638 so that we can review subsequent changes. Tests are failing for another reason (and are being fixed). I also had a look at updating the package and I see that we have issues where we rely on static linking of snap-seccomp to libseccomp where the static archive is not available. I will patch that out and iterate.

The current Arch package is merged in snapd master and I’m making progress towards updated packaging with all the features available in 2.27.

I made a few PRs to fix the issues I found (really tiny assumptions about some tests that broke when arch moved away from /snap). I should have a working package on AUR (snapd-git) soon.

The (current) list of fixes is:

Ok, I’ve made significant updates to the packaging and they are ready for more widespread testing.

Please look at this PR: https://github.com/snapcore/snapd/pull/3649

You can build snapd from this branch by going to the packaging/arch directory and running makepkg -sir. Note that this does not use your local tree but instead clones the master from github. This is not yet ready for integration with spread and local built package testing but this is a first step. My goal was to make it easy to update the Arch package in the community repository.

I’m also considering adding a snapd-git AUR package that would always track master. This could give us some more hands-on beta testing.

I made one more patch that fixed networking for my snaps:

https://github.com/snapcore/snapd/pull/3650

Does this mean that we can expect classic snaps to work on Arch soon? I ask because people have been wanting to use the compiler snaps I maintain on Arch. :wink:

No, because Arch maintainers moved away from /snap top-level directory and this is required by classic snaps to work. I can patch snapd to allow them to work if someone ahem makes a symlink /snap/var/lib/snapd/snap. Technically that is all there is to it. We also have an artificial check but that can be improved to look for the presence of the symlink as well.

I’ll add that tomorrow, I’m using plenty of classic snaps and I miss not having them.

2 Likes

Out of curiosity, what’s the reason why classic snaps have this strong dependency on being in /snap/?

Technically snaps using classic confinement don’t get the mount namespace that isolates them from the host distribution. They must rely on linker tricks to behave correctly. The only thing that keeps them operational today is the assumption that the linker is in /snap/core/current and that they are mounted in /snap/$SNAP_NAME/current/.

I wrote more technical details about this some time ago on my blog: https://new.zygoon.pl/post/state-of-classic-confinement/

1 Like

I’ve prepared an update to the Arch package but I cannot contact the downstream maintainer. For now I will add the patch and a binary package to the forum. Please help me test it.

EDIT: The package can be found on the snapd 2.27.3 release page on github: https://github.com/snapcore/snapd/releases/tag/2.27.3

Couldn’t you use bind mounts or overlay mounts to construct a “world view” that matches what Ubuntu-based classic snaps expect?

By this logic, Fedora-based classic snaps will work on Fedora and Arch, but not Ubuntu.

No, because classic snaps must execute with the same environment (including the mount namespace) as is in the real host and this would defeat that assumption. On top of this no reliable way of doing that exists as of today.

classic snaps may be based on any distribution but must adhere to the spec that says that they are mounted at /snap/$SNAP_NAME/current and that the core snap is mounted at /snap/core/current (or any base snap that they choose to go with at its appropriate location). That is literally the whole spec for classic confined snaps.

And 2.27.4 has been released in the same spot (github release page)

I got a question.

core stable is 2.26.14 version and while snapd is 2.27.4. What happen if i don’t update core stable? should i use the same version of core also?

http://imgur.com/a/SdEbR

You can not actually prevent that (unless you pull your network cable or some such). snap packages update themselves silently and automatically in the background.

I think on Arch linux you have to enable the service, on arch it doesn’t update automatically.

Because i haven’t enable the auto-update service

snapd manages the updating of snap packages internally, if you have snapd installed and running it will update your snaps as soon as new revisions of them show up in the store (and in the respective channel you have in use (typically “stable”))