I’d like to publish a classic snap of restic to the store. I am not the developer, but I have been having discussions with him regarding snapping it up. (he himself was not looking into snaps at all).
Restic is a backup utility written in Go.
INTRODUCITON
restic is a program that does backups right. The design goals are:
Easy: Doing backups should be a frictionless process, otherwise you are tempted to skip it. Restic should be easy to configure and use, so that in the unlikely event of a data loss you can just restore it. Likewise, restoring data should not be complicated.
Fast: Backing up your data with restic should only be limited by your network or hard disk bandwidth so that you can backup your files every day. Nobody does backups if it takes too much time. Restoring backups should only transfer data that is needed for the files that are to be restored, so that this process is also fast.
Verifiable: Much more important than backup is restore, so restic enables you to easily verify that all data can be restored.
Secure: Restic uses cryptography to guarantee confidentiality and integrity of your data. The location the backup data is stored is assumed not to be a trusted environment (e.g. a shared space where others like system administrators are able to access your backups). Restic is built to secure your data against such attackers.
Efficient: With the growth of data, additional snapshots should only take the storage of the actual increment. Even more, duplicate data should be de-duplicated before it is actually written to the storage backend to save precious backup space.
Free: restic is free software and licensed under the BSD 2-Clause License and actively developed on GitHub.
Classic confinement is required since this little utility is only useful when having full access to the file system (e.g. to backup files and directories, from any location the end user wishes to backup).
I have never requested a classic confinement before, so please let me know if you need any additional information.
My repo is currently sitting at:
I have a devmode snap sitting in the edge channel, and a classic version sitting in the beta channel (waiting for review).
I had typed most of this up prior to trying to push to the beta channel - so based on the text returned there - I likely did not have to submit here. But figured I may as well.
Good evening @jdstrand / @evan I suspect this is just due to the snap summit going on, but I just wanted to follow up in case there were some deficiencies on my end.
Apologies for the delay. Can you tell me more about your discussions with the author? Does he have any concerns accepting the yaml upstream?
I noticed you followed the Snapcrafters workflow for this, but didn’t propose it be hosted under github.com/snapcrafters. Would you be amenable to transferring the snap to Snapcrafters while still helping maintain it?
@evan - This can absolutely be moved to snapcrafters. Maybe I misunderstand the flow, but I thought we had to work our way through a few things and then would be moved over closer to the end (I still have some checklist items to complete prior to the transfer task). I have every intent for anything I do to get moved over to the snapcrafters repo. I also have no issues helping out there as well (already have a PR in on pulsemixer for some small fixes).
Otherwise my assumption was that once the item was in the snapcrafters, my interactions would be via PR’s.
Or did I misunderstand something?
Clarification appreciated as I have another snap almost ready to go for shfmt as well.
I’ve asked @Wimpress and @popey from Snapcrafters to join this thread and help migrate the GitHub repo and snap name. I’m +1 on classic confinement. As Gustavo points out, backup applications are good cases for classic.
I appreciate it! Should I hold of pushing this out to the store? I know they’re was discussed moving this to snapcrafters. I already have a test published under my name. Since I was working with the dev, I have the ‘restic’ name registered. However since the dev does not want to maintain, we can either leave with me, or transfer the name over as well.
Ideally I would recommend getting a snap working locally and propose a PR against the upstream project to add the yaml there. The upstream developer might need pointing at the relevant documentation for registering in the snap store, using build.snapcraft.io etc. But typically a pull request is the best place to have that conversation, on the upstream project.
If the upstream project refuse to accept the PR then we can host the yaml on snapcrafters for sure. Ideally though we’d prefer upstreams upload their own snaps to the store.
@popey the developer has already turned down this. He doesn’t want to maintain another distribution package.
This actually brings to light a question I’ve been thinking about. Is the idea with snapcrafters to maintain packages like this that may bring value to the ecosystem? Even if the upstream author does not want to maintain a snap package in today’s landscape? To summarize, is the goal to increase software availability? Or just to help developers get going using snap packages? I’d always assumed that there was an element of both based on the original forum post introducing the concept…
@bashfulrobot Yes, initially we started snapcrafters (group)as a way to quickly bootstrap a bunch of snaps into the store, and have a central place where ‘snapcrafters’ (people) such as yourself could put a snap which is building on behalf of an upstream software vendor. We too have had conversations with developers who are not interested in distributing Linux packages or snaps specifically. That’s fine of course. We need to understand why, so that we overcome misconceptions, inaccuracies or flaws in snapd or snapcraft themselves. Typically we will have a conversation with a developer and capture that in the form of bug reports, better documentation or tutorials - where appropriate.
In the end though, our goal should always be to get things upstream, so developers are empowered to take control of the distribution of their software. We don’t want to be the middle-man who dictates when a stable release goes out to their users, and we want them to have access to the metrics about how many people are installing their application. Currently that data is locked away in the snapcrafters store account, which is not optimal. I think there are moves to expose some of that data on the snapcraft.io store pages, but only in aggregate form.
So ultimately I’d like to only see things in the snapcrafters repo where we have tried to upstream, but if they say ‘no’, we can own it.
One flaw of the snapcraft repo we’re working to fix is that for many applications we don’t get automatic builds in the store when a new release goes out. Typically someone (a snapcrafter) will bump the version line in the yaml as a pull request, and perhaps nudge the source-tag or source url to pull the latest release of software. This is manual and not optimal. We’re trying to automate ourselves out of existence here, by adding version-script and prepare steps which set the version accordingly.
That just leaves the release step of pushing to the stable channel, which requires someone (myself, Ev or Martin) to do the snapcraft release to stable, but I’m looking to how we can make that less manual too, without risking unstable software hitting the stable channel.
