Perhaps this has been discussed, but I feel that the remixing side of open source has room for improvement within snap.
In an example, let’s say I created a fork of GIMP with some code changes, but not too many, and wanted to redistribute it. This doesn’t have to be a big project, but even just as a code test or an extension. Right now, I would create my own snap package, and then upload it to the snap store, resulting in duplicate GIMPs on the snap store (albeit mine has a different but similar name), which could cause clutter and possibly confusion.
Ideally, there would be something like snap remixes or community editions. You would have the official snap (say, GIMP in this case), and underneath it in the snap store would be a list of community forks which have some interest, but aren’t different enough to be separate apps. This way, the Snap Store would remain uncluttered from forks, yet fork makers would have easy ways to distribute their changed versions.
Gimp will soon have the extension manager and I hope the need for a snap fork won’t be needed then, but I may be wrong since snap seems to hide system libraries from the extensions and thus current gimp snap doesn’t support extensions or to be exact it brakes them.
I used GIMP only as an example, but it could be any package.
Even in Ubuntu, Ubuntu uses (AFAIK) a downstream version of GNOME Software. (How you would distribute an App Store as a Snap is not relevant to this.) In the case of this downstream version, you would ideally have the “official”, upstream GNOME Software listed in the Snap Store as “GNOME Software,” and then the Ubuntu downstream fork underneath that in the UI.
I am not sure the Snap store can scale to handle that, which might be why this hasn’t been discussed before. In the event that Snaps become uber popular and there’s a lot of forks of packages and people prefer to distribute in this manner, we’re going to have issues with scaling that, because the large central database model of the Snap store will likely need some re-architecting to handle that.
At least for the moment, it hasn’t been happening much, so we’re mostly safe here. But it’s definitely a problem that needs to be addressed eventually, somehow…
The unofficial way to publish your own build of a snap is to suffix the name of the snap with your username, for example keepassx-elopio is not created by the Keepassx project, but by elopio. However, the docs actually discourage this:
To register a name, log into your developer account and click “Register snap.” Pick the name that most represents your app. Do not prefix or suffix the name, for example with your username or “-snap.”
It discourages adding -snap because it’s a tautology. It’s a snap, no need for -snap in the name. It would be like calling a deb “chromium-deb.deb”.
The -name is discouraged merely because if you’re the upstream developer, you’re going to want to have the ‘real’ name in the store. Nobody is going to trust firefox-john even if “john” is the upstream developer at Mozilla. We’d much rather the genuine snap is owned and published by the upstream developer. Non-official ones can of course have suffixes, and that was in the original design for snaps. But we’d rather not have a “firefox-john” get super popular and then have the developer decide later “Actually, I’d like it to be firefox”, because right now, the store doesn’t support renaming of snaps. So it’ll be “firefox-john” for ever more, or they upload a second “firefox” snap and you end up orphaning the “firefox-john” snap and those users won’t get updates.
Our process for registering snaps is a little unfriendly right now. If you’re the genuine upstream developer of ‘foo’ and you snapcraft register foo it’s likely we pre-registered the name - even when no snap of that name exists (to prevent the land-grab and well meaning community people who don’t finish the project), you’ll get an error that it’s already registered. Even though it tells you to dispute the name, some people don’t.
So we have seen people who are the official upstream but they choose to use foo-john because they believe they aren’t entitled to use the official name, despite being the upstream. I filed a bug about this some time ago, and we really need to fix it, because snap name registration is a bit abrasive right now.
I believe that being able to fork and republish is an essential requirement of a FOSS ecosystem. For that, there should be a “snap source” command similar to “apt source” that would pull the snapcraft.yaml and all the other files, if any, necessary to build the package exactly as published.
Scalability of the snap store is a valid concern, obviously, but that just brings back once again the eternal problem of being able to create independent stores.
The store would have zero knowledge of the sources, since the sources aren’t uploaded to the store, only the produced binary snap. That’s sort of the point here. For Canonical’s goals, the snap store design is the correct one, since snapcraft isn’t designed to be a mandatory requirement for producing snaps.
Worth noting though that more recently the snap will optionally contain a manifest.yaml and snapcraft.yaml which enables users to work back and figure out where it was built and how. This is part of the infrastructure which makes it possible for us to send security emails to developers.
For example.
alan@hal:~$ ls -l /snap/ffmpeg/current/snap/
total 47
drwxr-xr-x 2 root root 55 Dec 28 16:58 gui
-rw-r--r-- 1 root root 38914 Dec 28 16:58 manifest.yaml
-rw-r--r-- 1 root root 8181 Dec 28 16:27 snapcraft.yaml
Here is the snapcraft.yaml and manifest.yaml from my hard disk, inside the ffmpeg snap. This gives the link to the build log, sources (if built from source) and included staged packages. If you set SNAPCRAFT_BUILD_INFO=1 before running snapcraft in your build system, it will add these artifacts to the build.
