"Snap" Linux packages - any experience?

This week it has been announced that the “Snap” package format will be included in many linux distributions (see here), and so I have started thinking that this might be the best format to distribute several of the photography-related tools we all use, and for which in most cases the official packages are severely outdated.

What do you think? Is there anyone with some experience of Snap packages that could give some help?

I guess that at least in some cases (like RawTherapee/Darktable/PhotoFlow/Filmulator) the structure of the packages would be rather similar, and therefore some work could be shared…

5 Likes

Supposedly snaps are really easy to build. There is also Flatpak from the Gnome team. And Appimg has been around for a while. I’d wait a bit unless you just want to play around.

The problem for me is figuring out how to deploy in the first place. Once I do that I can make an AppImage. Qmake is fairly confusing…

Standards

2 Likes

Dirk’s “rant” and the comments on it by many people are helpful, involving some big names:

https://plus.google.com/+DirkHohndel/posts/cFZLu9bEGx2

I don’t get why anyone would want to use such encapsulated packages. The main reason why I love Linux is its package management. I don’t have to hunt down every program’s website and regularly check for updates, then download them and come up with a nice way to store the binary blobs so that I find them when needed. Instead I just tell my system to install what I need and the daily dist-upgrade takes care of the rest. I would never give that up.

2 Likes

As far as I understand from the documentation, Snap packages are supposed to come with an “automatic update” system, pretty much like normal packages, but I might well have mis-interpreted the informations I could find…

Anyhow, I think that the concept is quite interesting especially for small projects with limited resources, which do not have active packagers for all major Linux distributions. The possibility to build “one package to rule them all” look very attractive.

Another interesting aspect is that one can easily roll back to any version, which might be very useful for unstable, bleeding edge versions that might contain serious bugs. Users of such versions would have in this case the possibility to easily roll back to the latest working version, or even have different versions installed in parallel. I can imagine that this could even improve bug-hunting.

I like the standard packaging systems for updating the System.

When it comes to production applications, I like to have access to the latest version with the least amount of trouble. If Krita 3.0 saves someone 10% of effort, if darktable gives me 10% faster image processing – getting the latest version without having to spend effort updating the rest of the system is worth it.

But I would like to know how/if my darktable Lua scrips would work with this encapsulated packages and the security stuff around it.

Btw. Boudewijn Rempt just wrote a nice blog entry about it:
http://www.valdyas.org/fading/index.cgi/2016/06/17#flatsnapimages

Very interesting read! I entirely share his point of view on traditional packaging for bleeding-edge end-user programs… it just doesn’t work. With PhotoFlow I have been struggling with binary-incompatible versions of EXIV2 and LensFun being pulled in by different PPAs, and the only reliable solution I have found is to bundle some of them into the photoflow sources. Same concept, only at a smaller scale…

I do not have the technical backgroud to judge if AppImage is better than Snap or vice-versa, but I’m now really tempted to spend some time making a PhotoFlow.appimage and see what this will bring.

Another interesting read about the “Snap” story, written by Adam Williamson: https://www.happyassassin.net/2016/06/16/on-snappy-and-flatpak-business-as-usual-in-the-canonical-propaganda-department/

I had some down time today, was feeling very impatient, and decided that I’d see how easy it is to use each of these technologies. The machine I was using is a 5th generation Intel i5 NUC (2 cores, hyperthreading) with 16 gb RAM and a 128 GB M.2 SSD with Ubuntu Mate 16.04; not the fastest machine, but plenty to reasonably run the usual graphics applications, GIMP, Darktable, and RawTherapee.

All three formats, snap packages, flatpak, and appimage look reasonably easy to operate.

Technically snap packages should’ve had a leg up, as the snap program was installed by default. I listed the available packages with snap find to see what was available and it was mostly terminal applications like tmux and htop. Try to install tmux with snap install tmux, but you need to log into the store with your account to install the tmux snap packge. I’m sure that’ll work for some people, but not for me.

On to flatpak. Install the gnome run time (supposedly KDE is working on their own runtime as well), the list the available applications. Most of the default gnome desktop applications. I successfully installed gedit, but it was pretty slow to load up.

The only appimage package I was really aware of was Krita, so I grabbed that package from krita.org, chmod a+x krita.appimage, then ./krita.appimage and soon I was greeted by the Krita screen. It seemed pretty responsive, and I like that there was no run time or any other package needed make Krita run. In another 30 seconds of searching, I found that the appimage project builds a bunch of linux programs already. When you run the appimage for the first time, it asks you if you want to install a shortcut, so that it’ll show up in your menus, I thought this was a nice touch. It seems to run well, I’m now using an appimage for Darktable, GIMIP 2.9, Scribus 1.5, and Sigil 0.9.5.

EDIT: Sadly the version of GIMP seems not to work :frowning:

1 Like

Mika, your tests are really interesting!

I personally don’t like the idea of logging in to install the snap packages, it looks too much like Google’s app store! :frowning:

Is there a way to know who maintains the darktable appimage package?

Thanks!

I was very displeased to have to log into the snap store as well. I’m for centralized, easy distrirbution, but I use linux so that I don’t have to deal with corporations tracking what I do. Canonical have brushed aside the criticism though, saying it’ll be opened eventually.

If you want to know who maintains the darktabe package, you could open an issue on their github. But if you look at the build file for it, it uses Pascal’s PPA and the just shoves all the libs into a bin and static links them, then auto builds the appimage. They also look like they’re auto built.