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.
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.
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.
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.
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.
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’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.
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.
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.
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”))