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

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.

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.