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.

On Sunday, 29 January 2017 at 20:07:50 UTC, Joseph Rushton Wakeling wrote:
> I started by trying to snap LDC, mainly because the cmake build system made for a very easy integration with the snapcraft package-build system.  The LDC developers have been kind enough to accept this as an official contribution, and a first submission is currently waiting for review in the Ubuntu snap store, based on the following package definition:
> https://github.com/ldc-developers/ldc2.snap

This LDC snap is now published in the official snap store.  See:
https://forum.dlang.org/thread/rkxyvsmgwhfkigybjpig@forum.dlang.org

... for more details.