snap package enablement

[kubiko]

First shot to upstream snap support

[pemensik]

Why does this add Snap specific patch into the repository? Is PID == 0 something special in Snap? I think the check might use a configure time flag, but it should be in the upstream sources in final way. Not sure we can safely assume any process 0 cannot exist

[evverx]

I don't think it should be kept upstream. All this packaging stuff should be maintained by whoever ships snaps (by analogy with how for example Debian and Fedora maintain their packages).

Let's close this.

[evverx]

@lathiat I didn't know you were interested in this. Sorry!

My reasoning was that to fully officially support snap (or any other way of packaging and deploying avahi) upstream it should be tested upstream in the sense that the CI should make sure that it can be built and deployed properly. It should be fixed upstream too. Without that it's just a bunch of files that make it look like it's supported upstream.

(All in all I think downstreams with their testing infrastructures are usually much better at packaging stuff that works in their environments).

[pemensik]

Snapcraft is pushed hard by Ubuntu, they are planning to have everything serious in Snaps. Including system services like printing. In that way it is not just flatpak alternative. That was my impression from Ubuntu Summit in Prague. Not interesting to me as I think it belongs to the base system, but won't stop others preparing its proper support.

[lathiat]

It’s all good :) I’ll sort this one out.

[lathiat]

@evverx btw, don’t be afraid to close stuff generally.

On the odd chance I want to do something different I’ll rescue it but probably won’t be many.

[evverx]

Not interesting to me as I think it belongs to the base system, but won't stop others preparing its proper support.

@pemensik I think "proper" is the key word here. For example in its current form avahi is run with --no-drop-root and that's probably not the best way to do it. I suspect the idea is to rely on "confinement: strict" and hope for the best but what happens if the avahi snap is run in Ubuntu containers on, say, a Fedora machine where all the AppArmor stuff is off and snapd.apparmor.service contains ConditionSecurity=apparmor? :-) Does this snap work if it's run in rootless containers? Why does it say that it works on armhf and risc? Has it been actually tested there? I have no idea. Normally questions like that should be directed to whoever maintains this and is responsible to make all the integrations work properly. If it's kept upstream it means that questions like that are going to be directed upstream (and I'm not sure it's the right place).

[evverx]

Before I forget I was curious so I installed avahi from https://snapcraft.io/avahi on Ubuntu (and I assume it's based on this PR more or less). It brings /etc/dbus-1/system.d/snap.avahi.daemon.conf (which makes org.freedesktop.Avahi visible):

busctl list | grep Ava
org.freedesktop.Avahi     5107 avahi-daemon    root            :1.56         snap.avahi.daemon.service   -       -

but it comes without org.freedesktop.Avahi.Server.xml so it isn't introspectable:

busctl tree org.freedesktop.Avahi
Only root object discovered.

May 31 22:20:14 63354d0c5e0f avahi.daemon[5107]: dbus-protocol.c: interface=org.freedesktop.DBus.Introspectable, path=/, member=Introspect
May 31 22:20:14 63354d0c5e0f avahi.daemon[5107]: Failed to open /usr/share/dbus-1/interfaces/org.freedesktop.Avahi.Server.xml: No such file or directory
May 31 22:20:14 63354d0c5e0f avahi.daemon[5107]: Failed to load introspection data.
May 31 22:20:14 63354d0c5e0f avahi.daemon[5107]: Failed to open /usr/share/dbus-1/interfaces/org.freedesktop.Avahi.Server.xml: No such file or directory
May 31 22:20:14 63354d0c5e0f avahi.daemon[5107]: Failed to load introspection data.

All the methods can still be called directly:

May 31 22:28:36 63354d0c5e0f avahi.daemon[5273]: dbus-protocol.c: interface=org.freedesktop.Avahi.Server, path=/, member=GetAlternativeHostName
May 31 22:28:36 63354d0c5e0f avahi.daemon[5273]:  [63354d0c5e0f.local]: alternative.c:112: avahi_alternative_host_name: Assertion `avahi_is_valid_host_name(r)' failed.
May 31 22:28:36 63354d0c5e0f systemd[1]: snap.avahi.daemon.service: Main process exited, code=dumped, status=6/ABRT
May 31 22:28:36 63354d0c5e0f systemd[1]: snap.avahi.daemon.service: Failed with result 'core-dump'.
May 31 22:28:36 63354d0c5e0f systemd[1]: snap.avahi.daemon.service: Scheduled restart job, restart counter is at 6.
May 31 22:28:36 63354d0c5e0f systemd[1]: Stopped Service for snap application avahi.daemon.
May 31 22:28:36 63354d0c5e0f systemd[1]: snap.avahi.daemon.service: Start request repeated too quickly.
May 31 22:28:36 63354d0c5e0f systemd[1]: snap.avahi.daemon.service: Failed with result 'core-dump'.
May 31 22:28:36 63354d0c5e0f systemd[1]: Failed to start Service for snap application avahi.daemon.

but stuff relying on any sort of introspection doesn't work.

I think it's a good example of a packaging issue that shouldn't be brought upstream.