Why do snap-packages exist - is there a real need?

Assumptions

Honestly, I do not know much about snap-packages - but this is irrelevant for this question - see below. I assume the system is significantly different from the existing one.

Does the change make sense?

Is there an actual need, strong enough? That is - is there a new use case, that is important enough to develop a new format - and the associated infrastructure?

Was it not feasible to change the current method to cover the new use cases too?

Or am I missing the point?

It is possible that what I see is mostly marketing - new names and presentation for minimal technical change, to get a chance that any body assumes it as "new and better" and it may be actually used. Also, it may be that the new packages are so closely based on the existing format that it is mostly a change in presentation to the user. That could be a good solution, of course. In this case, this question would have not much relevance.

Then, I would hope that is still useful enough to answer to side aspects. Just let me know if the question is not helpful or confusing to new users, I'm happy to delete it.

So, why do they exist?

Background

My first reaction was "That makes no sense!"

This is similar to a situation where, on the physics site, someone asked, unhappy, why nobody discusses his brilliant new ideas in answers. It looked strongly like crackpot ideas; So far from actual physical knowledge that it was hard to find a point to even start. I wrote an answer that did not touch his ideas with a single word, but explained why one would just not discuss assuming crackpot ideas - not the first case of that. The answer was actually hitting the point, I think.

If my assumptions were right, this case is similar.

But then, maybe not - let's see.

Solution 1:

Yes, there is a real need.

There has been a real need for something like this since the first time one software depended on another.

Let's make this clear:

Managing dependencies is hard.

There's a reason why it's called dependency hell. Packaging systems like RPM and Debian were created with the intent of avoiding dependency hell. However, somebody must pay the cost:

1. On Windows, where programs bundle their dependencies, the user has to take care of upgrades (and any security problems from lack thereof). If I the dev want version X of something for my app, simple: I provide it with my app. Now how do I handle updates?
2. On most Linux distros (following Debian or Red Hat), where a program can depend on software from the repository, a program from the repository must depend on software from the repository. If I want version X of something for my app, and the distro provides X, simple: I depend on it. And if the distro doesn't? Then: ???
   • Adding multiple versions to the distro increases the load on the maintainer
   • Losing the ability to use the version of choice of dependencies increases the load on the developer
   • Losing the ability to use the version of choice of applications frustrate the user

There is a considerable loss of freedom in either method.

And this is where snaps come in: they let the dev include version X, and let the packaging system manage updates. Who pays the cost? The user:

• by requiring more space.
• by putting them at risk due to a careless dev not rebuilding their snaps when a dependency is patched.

What benefits do I get, in exchange?

• Aside from security via updates (which, frankly, not enough people care about), I the user don't have to worry about dependencies with snaps. The word mostly loses meaning.
• Aside from security updates, the software developer doesn't need to worry about getting users to install the correct dependencies.

Solution 2:

One particular feature of snaps which might be useful is the ability to choose a channel for developers that provide more than one channel, such as release, candidate, master, etc.

For example, clicking the Channel button for nextcloud will show the dialog in the screenshot below.

The other strong selling points are isolation, immutability, and sandboxing which are controlled by a security policy context, which allows defining per-app permissions, also called 'plugs' for e.g.:

• read/write locations
• access to removable storage
• countries where the snap is whitelisted/blacklisted
• network access
• camera, printer, joystick, GPS location
• system settings
• ...full list of snap interfaces

The approach mimics to some degree the MacOS app bundles and Android's app sandboxing with permissions and content providers/receivers.

Now, imagine you need to run a dozen of apps each with its own version of certain libraries, its own version of Python/Ruby/NodeJS runtime and you don't want to run into dependency hell and mess up or pollute your system libraries, your system Python/Node/Perl/Ruby modules, etc..

Real-life use cases

• On a raspberry pi 4 the latest version of PHP available in the repos is 7.3 and if you by chance need to run something that requires a higher version (e.g. a newer version of nextcloud) then you would have to find a way to do it bypassing the ootb package manager, which in turn might break other packages or cause instability. Running nextcloud as a snap lets you run the version you want no matter what dependencies you have installed by default via the system package manager. Moreover, the snap has the option to autoupdate itself which can also come in handy.

• you need to run concurrently different versions of the same web-server, for example, apache2, nginx or caddy because you have multiple apps each requiring a specific version.