Snap packages for D compilers and core projects

[Joseph Rushton Wakeling via Digitalmars-d]

On Friday, 3 February 2017 at 08:51:38 UTC, qznc wrote:
> I just tried FlatPak and Snap. Snap is actually useable.

One of the first things that struck me about snap packaging was 
the ease of its syntax and how straightforward it was to get 
things working.  I actually started creating snap packages as an 
easy way to build and install D compilers and other tools on my 
own system.  It's both simpler and cleaner than doing those 
builds by hand or writing custom scripts.

The fact that it's then trivially easy to share the results with 
everyone else is the cherry on the cake :-)

> FlatPak might be superior technology with its sandboxing, but 
> I'm no expert. FlatPak has no central repository, which makes 
> it unuseable for the layman at the moment. It feels like the 
> PPA situation in Ubuntu.

I'm no expert on sandboxing either, but snapcraft certainly also 
provides confinement -- and to be honest my impression is it does 
so in a more effective and flexible way than Flatpak.  Some of 
the non-Ubuntu distros may however be disabling the confinement 
right now as some issues with different confinement systems are 
worked through.

> Snap has stuff like pulseaudio (audio daemon) or ogre 
> (rendering engine) in the repo. That seems weird, because these 
> are not applications. The first belongs into the base system, 
> the second into a development environment.

I think this is by design.  For example, it makes perfect sense 
that a daemon like pulseaudio might live in an isolated, confined 
environment where only applications that specifically need access 
are allowed to talk to it.  Probably its presence in the store is 
in order to allow people to explore working with it in that way.

I can't speak to ogre, but I don't think the use-cases of snap 
packaging are intended to be limited to applications in the long 
run.  It also makes sense that a development library could be 
provided via a read-only filesystem, so that while anyone might 
_read_ it to build or run a program, it couldn't be overwritten 
by another application.

For an example of a library snap, I believe some core KDE 
frameworks are being distributed as a snap in their own right, 
which other KDE application snaps can then depend on.