Just pushed a new revision of these changes removing the redundant snap wrapper I had inadvertently checked in. The snapper isn't required as the commands to start and stop Synapse can easily be added to the snapcraft.yaml in the case of Synapse, given the availability of synctl

I'm afraid we've dismissed this in the past: #4484

(but thank you for the contribution!)

Is there any opportunity to reopen this as a discussion around publishing synapse as a snap package?

I have reviewed the previous PR, and given it was back in January, a fair bit has changed around snapcraft and snaps. I think at least having the packaging files present in the repo would be useful for folks.

As I see it, the main issues boiled down to:

• Support burden
• GitHub credentials
• Maintenance of the snapcraft packaging metadata
• Docker

As you will see by reviewing the snapcraft I have put together, I have tried to write the package in the most minimal way possible. This snap is calling synctl, which mirrors the upstream guidance on how to stop and start synapse directly. This thin shim gets placed into a systemd unit on the host, and the commands are executed inside the snap's overlay filesystem.

Snaps, unlike Docker, are not a container - think of them more as a package that runs in a chroot (like many common daemons, postfix, for example). There is some additional isolation that is configured, but there is no support burden of this, as this snap exposes the network and network-bin plugs, which are automatically connected on install. Connecting a plug is like granting a permission, it's not an ongoing item that requires support, and as these are autoconnected plugs, the user does not have to do anything other thant 'sudo snap install matrix-synapse'.

From the perspective of support burden, I would be more than happy to take over all snapcraft related inquiries and support questions, as well as maintaining the snapcraft package if required to keep up with changes. None of these would be surprising in my opinion, as any change that would break snapcraft would be very likely to break most if not all other packaging mechanisms supported today.

As to the GitHub question, that is only for automatic publishing. And there are no credentials to maintain - the snapcraft store authorizes as a GitHub 'application' and then monitors the repository using its read access so it can build and publish snaps (this does not require any additional infrastructure for the Matrix project) automatically as commits are pushed. I have structured the snapcraft in such a way that the existing git metadata will automatically be used to set versions.

Providing this snapcraft metadata and hopefully discussing the use of snaps is part of a larger goal of mine, as I would like to make Matrix and the appservice bridges as easy for people to install and keep up to date as possible - and snapd fits that well. I am also in the process writing a Juju Charm to aid in installing and configuring a Matrix homeserver for folks, which I think will help the adoption of Matrix, a very important goal in my mind.

Anyhow, thanks for reading this. I hope you'll reconsider and we can have a discussion about this - but either way, I wanted to make sure the decision was being made with up to date information and my offer to take up any support related inquiries.

ok, I'll reopen this and we can reconsider.

Thanks, greats news.
If I wanted to help in supporting any snapcraft-related issues, what would be the best way to get involved?
Also, if I wanted to publish this myself on the snap store, would there be any objection or conditions you would like to place around that?