keep stable backward compatible with debian 11(snap 2.49)

[telepath]

Debian 11 currently has snap version 2.49. Freecad requires version 2.55, meaning it's not compatible with debian 11 anymore. Please consider adding such bleeding-edge requirements only for --edge snaps, not for stable.

$ snap --version
snap    2.49-1+deb11u1
snapd   2.49-1+deb11u1
series  16
debian  11

[telepath]

Also note that even debian testing only has snapd version 2.54.

[ppd]

Debian should support re-execution (https://forum.snapcraft.io/t/does-the-snapd-daemon-automatically-update-itself/29041/2) and thus automatically use a newer snapd if available from the snapd snap (or the core snap).

@luzpaz what do you think? Cups out, snapd requirement lower for stable?

[telepath]

Well, for me, it does not work:

user@cad:~$ snap refresh core
snap "core" has no updates available
user@cad:~$ snap install freecad
error: cannot perform the following tasks:
- Mount snap "freecad" (66) (snap "freecad" assumes unsupported features: snapd2.55 (try to update snapd and refresh the core snap))
- Mount snap "cups" (766) (snap "cups" assumes unsupported features: snapd2.55 (try to update snapd and refresh the core snap))

[telepath]

I found the workaround:

user@cad:~$ snap install snapd
2022-06-24T18:25:42+02:00 INFO Waiting for automatic snapd restart...
snapd 2.56 from Canonical✓ installed
user@cad:~$ snap --version
snap    2.56
snapd   2.56
series  16
debian  11

This is the official snapd package available via snap, but it doesn't seem to be very well documented. The docs only say to update the core package, which does not help in this case. So the issue is more a usability issue, maybe a comment could be added in the readme?

[ppd]

Yeah, that is the re-execution functionality. I'm curious why the Debian packages do not have a hook to install the snapd snap by default. Maybe there's a Debian policy against it.

[telepath]

Also, there is another issue:

user@cad:~$ snap install freecad
error: cannot perform the following tasks:
- Run configure hook of "freecad" snap if present (run hook "configure": cannot locate base snap core20: No such file or directory)

I was able to solve this by installing core20 from --beta:

user@cad:~$ snap refresh core20 --beta
core20 (beta) 20220614 from Canonical✓ refreshed
user@cad:~$ snap install freecad
freecad 0.20 from FreeCAD (freecad-org) installed

[ppd]

Very strange. Maybe that's a case for the snapd developers; such measures should never be required.

[telepath]

All in all, I'd still prefer to avoid the bleeding-edge approach. Everything worked without any issues before, this seems to add complexity and a lot potential for issues.

[luzpaz]

That's a long time to support Debian 11.

Edit: I'm concerned about the potential overhead on volunteer maintainers to troubleshoot 3rd-party dependencies for distros like Debian.

[ppd]

Everything worked without any issues before, this seems to add complexity and a lot potential for issues.

Everything except the printing.

@luzpaz Debian 11 uses (should use) snapd from the store. Why this went wrong here is the question. Maybe one has to restart once for snapd to re-execute from the core snap.

[luzpaz]

@ppd but cups (printing support) is important. Am I understanding correctly that we're removing cups until Debian 11 completes it's lifecycle in 2026 ?

Debian 11 uses (should use) snapd from the store. Why this went wrong here is the question. Maybe one has to restart once for snapd to re-execute from the core snap.

If we could get this bug fixed then that would be the more ideal solution

[telepath]

Personally, I'd be completely fine with supporting only the latest debian release version, but for now, that's 11. The expectation for a snap is that I can install snapd, then the snap, and it works. Currently, that's not the case for debian 11. I guess it's a decision if that's the desired result for freecad, in the end it's always a balance between supporting new features and compatibility. If the default debian setup is not supported out-of-the box, that should be mentioned in the readme/description. After all, people can still use the appimage if the snap is not working or too complicated to set up.

[ppd]

We can still support older snapd versions by going a different route for cups support. I believe users must then explicitly grant permission to the snap, but at least that's a non-issue at installation time then.

Why you have those issues in the first place is a question for forum.snapcraft.io. I'll probably post it there soonish when I find the time.

[ppd]

https://forum.snapcraft.io/t/re-execution-prerequisites-on-debian/30650

[luzpaz]

Big props to your awesome bug reporting skills, @ppd

[ppd]

I can't reproduce the issue in a Debian 11 container:

root@rexectest:~# apt install snapd
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Suggested packages:
  zenity | kdialog
The following NEW packages will be installed:
  snapd
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 13.3 MB of archives.
After this operation, 56.4 MB of additional disk space will be used.
Get:1 http://deb.debian.org/debian bullseye/main amd64 snapd amd64 2.49-1+deb11u1 [13.3 MB]
Fetched 13.3 MB in 2s (5365 kB/s)
debconf: delaying package configuration, since apt-utils is not installed
Selecting previously unselected package snapd.
(Reading database ... 12749 files and directories currently installed.)
Preparing to unpack .../snapd_2.49-1+deb11u1_amd64.deb ...
Unpacking snapd (2.49-1+deb11u1) ...
Setting up snapd (2.49-1+deb11u1) ...
Created symlink /etc/systemd/system/multi-user.target.wants/snapd.recovery-chooser-trigger.service → /lib/systemd/system/snapd.recovery-chooser-trigger.service.
Created symlink /etc/systemd/system/multi-user.target.wants/snapd.seeded.service → /lib/systemd/system/snapd.seeded.service.
Created symlink /etc/systemd/system/cloud-final.service.wants/snapd.seeded.service → /lib/systemd/system/snapd.seeded.service.
Created symlink /etc/systemd/system/multi-user.target.wants/snapd.service → /lib/systemd/system/snapd.service.
Created symlink /etc/systemd/system/sockets.target.wants/snapd.socket → /lib/systemd/system/snapd.socket.
Processing triggers for dbus (1.12.20-2) ...
root@rexectest:~# snap --version
snap    2.49-1+deb11u1
snapd   2.49-1+deb11u1
series  16
debian  11
kernel  5.15.0-40-generic
root@rexectest:~# snap install core
2022-06-28T08:56:35Z INFO Waiting for automatic snapd restart...
core 16-2.56 from Canonical✓ installed
root@rexectest:~# snap --version
snap    2.56
snapd   2.56
series  16
debian  11
kernel  5.15.0-40-generic

[luzpaz]

Weird

[telepath]

You're right, I can't reproduce any of the issues anymore, either.

$ sudo apt install snapd
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following NEW packages will be installed:
  snapd
0 upgraded, 1 newly installed, 0 to remove and 116 not upgraded.
Need to get 13.3 MB of archives.
After this operation, 56.4 MB of additional disk space will be used.
Get:1 https://deb.debian.org/debian bullseye/main amd64 snapd amd64 2.49-1+deb11u1 [13.3 MB]
Fetched 13.3 MB in 1s (10.8 MB/s) 
Selecting previously unselected package snapd.
(Reading database ... 100301 files and directories currently installed.)
Preparing to unpack .../snapd_2.49-1+deb11u1_amd64.deb ...
Unpacking snapd (2.49-1+deb11u1) ...
Setting up snapd (2.49-1+deb11u1) ...
Created symlink /etc/systemd/system/multi-user.target.wants/snapd.recovery-choos
er-trigger.service → /lib/systemd/system/snapd.recovery-chooser-trigger.service.
Created symlink /etc/systemd/system/multi-user.target.wants/snapd.seeded.service
 → /lib/systemd/system/snapd.seeded.service.
Created symlink /etc/systemd/system/cloud-final.service.wants/snapd.seeded.servi
ce → /lib/systemd/system/snapd.seeded.service.
Created symlink /etc/systemd/system/multi-user.target.wants/snapd.service → /lib
/systemd/system/snapd.service.
Created symlink /etc/systemd/system/sockets.target.wants/snapd.socket → /lib/sys
temd/system/snapd.socket.
Processing triggers for man-db (2.9.4-2) ...
Processing triggers for qubes-core-agent (4.1.33-1+deb11u1) ...
Processing triggers for dbus (1.12.20-2) ...
Processing triggers for mailcap (3.69) ...
Processing triggers for desktop-file-utils (0.26-1) ...
$ snap install freecad
2022-07-01T14:02:14+02:00 INFO Waiting for automatic snapd restart...
freecad 0.20 from FreeCAD (freecad-org) installed

It works fine now. I don't know what changed, or if it was a bug or something just took some time to be available on debian? Maybe this type of problem could be avoided with automated testing? Setting up an action that tests the installation on different distributions should be possible. It seems in this case just waiting a few days solved the problem.

[ppd]

Maybe this type of problem could be avoided with automated testing?

There's a massive suite of integration tests for snapd: https://github.com/snapcore/snapd/tree/master/tests Debian 10, 11, and sid are configured as backend systems, as far as I can see. I'm pretty sure there are tests dealing with this very important feature somewhere in there.

As a software engineer, I'd prefer to have meaningful (!) integration tests for the FreeCAD snap, of course. But I wouldn't want to test snapd features, such as this re-execution support on Debian, downstream; such tests belong in the snapd project itself.

[telepath]

I just feel the minimum requirement for release of a new version should be that it actually runs, or at least installs on major/supported distributions. Another solution is to only support Ubuntu, since it has the best support for snapd. As I said before, everyone else can still use the Appimage, if the snap does not work for some reason. I would like to see a statement what is supposed to work. If you only support Ubuntu and it does not work on Debian, I know I don't need to bother anyone. And in this case, the problem would still have gone away a week later by itself.

[luzpaz]

Aside, I'm surprised that https://forum.snapcraft.io/t/re-execution-prerequisites-on-debian/30650 didn't get any traction on the forum

[ppd]

@luzpaz Probably because no one has experienced this problem so far. I couldn't reproduce it either, so it must be a very specific state or environment that triggers this bug.

I would like to see a statement what is supposed to work.

That's encoded in the assumes: [snapd2.55] part. A good part of the appeal of snaps is that the developer does not have to care too much about the target host. If the snapd maintainers support the distribution, it should be good to go, provided snapd is recent enough.

What we're actually trying to do is to go away from "we support distribtions x,y,z" to "we support the snap base core20". The application only sees the core20 environment, which is set up by the snapd program.

I just feel the minimum requirement for release of a new version should be that it actually runs, or at least installs on major/supported distributions.

A poor-man's integration test suite could be implemented by installing LXD in the GH Action environment (Ubuntu) and then launching different containers with various distributions (https://uk.lxd.images.canonical.com). Of course, then you'd have to set up those containers just right, because snapd needs access to a few features that are not available by default in unprivileged containers. Then this becomes a bit of a time-consuming task, and the result will probably break subtly at some point. At that point, I'd rather trust the snapd developers to be doing their homework, for which they actually get paid.

[luzpaz]

Thanks for all the elaborations @ppd. You rock.