Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Add snapcraft packaging information #6084
Signed-off-by: James Hebden email@example.com
This PR adds packaging metadata to allow snaps (https://snapcraft.io) to be built automatically and published to the snap store, where people can install Synapse by running
I am also happy to assist in the publishing of this package to the store, and maintaining any snap-related matters in regard to any part of the Matrix ecosystem.
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
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:
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.
Thanks, greats news.