Linux Mint drops Ubuntu Snap packages

Posted Jul 8, 2020 20:37 UTC (Wed) by simosx (guest, #24338)
Parent article: Linux Mint drops Ubuntu Snap packages

You could create your own Snap Store, and there was even a blog post and a Github repository for this, at https://ubuntu.com/blog/howto-host-your-own-snap-store (2016-2017).

However, `snapd` progressed and switched to protocol version 2.
The API is documented, https://github.com/snapcore/snapd/wiki/REST-API
Both the service (snapd) and the client (snap) are available, https://github.com/snapcore/snapd
If someone is really interested in creating a third-party Snap Store, they can figure it out rather easily.

You can either build your own snap package yourself, and then upload to the Snap Store.
Or you can use the Build service, and it builds snap packages for you, for six architectures (amd64, i386, armhf, arm64, ppc64el, s390x).
It should be possible to create reproducible snap packages because these are built in VMs.

There are 30000 packages in the APT package-management system. There are hand-crafted, and the packaging adheres to the Debian rules of splitting the dependencies in separate packages. If there is a new version of the source code of a package, it needs the packaging maintainer to perform the update. There is much more effort in doing all these, and there are always too few people to help.
If anyone wants to check, they can parse these packages and report back when they were last updated. I would be interested to see the results.

Linux Mint drops Ubuntu Snap packages

Posted Jul 8, 2020 20:58 UTC (Wed) by dowdle (subscriber, #659) [Link] (5 responses)

Looking at the link for the snapstore software, it currently reads:

'snapstore was a minimalist example of a "store" for snaps, but is not compatible with the current snapd implementation. As a result I have removed the contents here to avoid further confusion.'

Linux Mint drops Ubuntu Snap packages

Posted Jul 9, 2020 5:39 UTC (Thu) by simosx (guest, #24338) [Link] (4 responses)

You just revert the last commits that removed the code, and you get the latest version that was available at the time.
Note that this is a starting point for someone that would like to start implementing a third-party Ubuntu Store.

If you are not using command-line tools, you can look at the top-right corner at https://github.com/noise/snapstore
where it says that there are 22 forks. Click on the **22**, and it will take you directly to repository forks that show the source code.

Linux Mint drops Ubuntu Snap packages

Posted Jul 10, 2020 17:30 UTC (Fri) by atnot (guest, #124910) [Link] (3 responses)

At this point, why not just use Flatpak which is both not hostile to users of the technology and technically superior in several aspects.

Linux Mint drops Ubuntu Snap packages

Posted Jul 10, 2020 21:54 UTC (Fri) by simosx (guest, #24338) [Link] (2 responses)

> At this point, why not just use Flatpak which is both not hostile to users of the technology and technically superior in several aspects.

There is too much such evangelism. The reality is that there are all sort of issues. The sandbox permissions are set by those that package the application. Kinda defeats the purpose of a sandbox.

Linux Mint drops Ubuntu Snap packages

Posted Jul 12, 2020 18:31 UTC (Sun) by atnot (guest, #124910) [Link] (1 responses)

This is no different from the sandboxes on any other platform. The app declares the permissions it needs and users can modify them as needed. The only way in which I see your argument is that the flatpak cli does not ask you to confirm the permissions before installing. Which it definitely should, but has little to do with flatpak as a technology.

Linux Mint drops Ubuntu Snap packages

Posted Jul 13, 2020 17:37 UTC (Mon) by mathstuf (subscriber, #69389) [Link]

It'd be great if dummy backends could be used. This makes the apps not have to deal with missing permission checks (and potentially refusing to work if not provided them) and keeps your data safer.

Linux Mint drops Ubuntu Snap packages

Posted Jul 9, 2020 9:15 UTC (Thu) by guus (subscriber, #41608) [Link] (2 responses)

Regarding not enough manpower to properly maintain packages: the vast majority of the packages in Debian and its derivatives require very little work; it's just a few commands for a package maintainer to download a new upstream version and have a new package version created. Also, most packages see very few changes that need to be backported. The problem is that Chrome does not have LTS releases, and they have a breakneck development pace, so it is impossible for package maintainers to backport all the bug fixes in the upstream project to the stable version in their Linux distribution. The best thing you can do is upgrade a package like Chrome to a newer upstream version. That might be fine until they also start depending on newer versions of libraries than you have in your stable distro release, because then you really won't have a stable release anymore.

The snap packages are a way to circumvent the principles of a stable distro release. I personally think it's a bad idea, because now you will never get a stable version of Chrome, you will just get the latest version that fixed the old bugs but comes with a whole bunch of new bugs. It would be much better if Chrome would have LTS releases every two years or so that the Linux distributions can sync with.

Apart from all that though, I don't see a technical reason why they couldn't make a proper deb package of the latest version of Chrome + a copy of the libraries they need, with a source version, so you can reproducibly build it, and without needing yet another package management system.

Linux Mint drops Ubuntu Snap packages

Posted Jul 9, 2020 11:39 UTC (Thu) by simosx (guest, #24338) [Link]

> The snap packages are a way to circumvent the principles of a stable distro release.

In a typical snap package, you specify the APT package of a dependency. Does not deviate much from the process in creating a deb package.

In the very special case of Chromium, a specific new version is just a branch of the upstream source code with several of the dependencies added in there.
Here is the cloned repository of Chromium that is used to create the snap package, https://code.launchpad.net/~chromium-team/chromium-browse...
The snapcraft.yaml file that creates the snap package is https://git.launchpad.net/~chromium-team/chromium-browser...

I do not know if you are packaging software in Debian or another Linux distribution. If a software is actually being developed, things change, and when you try to package a new version and you get issues, then it opens up a big fat can of worms. You may create a patch to make it work. You may communicate this patch with upstream, and then figure out whether it has been applied, fully or partially. How do you test whether the software actually works? Do you test it? Actually, it would make better sense if the developer had an installation package and have them test it themselves. Because they are more suitable to figure out if something does not work. In fact, with snap packages, a developer can use the automated Build server to create snap packages, test them, and then flip a switch to push to the Snap Store.

Linux Mint drops Ubuntu Snap packages

Posted Jul 11, 2020 9:57 UTC (Sat) by riteshsarraf (subscriber, #11138) [Link]

Similar was the case of (Oracle) VirtualBox in Debian. Post the take over of the company, the release process changed and left not much choice for its maintenance in a Debian Stable release, for example.

In my observation, there's been multiple reasons for such act.

* Competition: OEL vs RHEL. Similar situation occurred when one took over work from other, such that broken down changes were stopped being released.

* Maintenance: Maybe maintaining stable branches is too much of a hassle. And perhaps Linux LTS is just an exception to it.

* USP: Everyone wants something.