diskutiert. Dennoch ist das Problem immer noch existent und kann derzeit nur dadurch behoben werden, dass man bei 2 snap packages auf den candidate channel wechselt.
Nachdem ja erst kürzlich festgestellt wurde, dass snap packages NFS shares die autofs nutzen nicht erkennt und somit mit Dateien in diesen Verzeichnissen nicht arbeiten kann, muss man als zweiten großen Nachteil erwähnen, dass alle lokale Konfigurationen inkompatibel zur LSB innerhalb des Unterordners ~/snap gespeichert werden.
Falls man dann das snap package jemals durch ein nicht-snap package ersetzt wird das erneuerte Programm, bspw. unterhalb von:
~/.config ~/.local
nichts vorfinden und mit einer leeren Userkonfiguration starten.
Je mehr man sich mit snap packages beschäftigt, je offensichtlicher tritt zutage, dass snap packages zwar mit den Nachteilen der klassischen SW Repositories (ppa) aufräumten, aber dafür mindestens ebenso gewichtige neue Nachteile – die der Containerisierung und Abgrenzung – einführten. Der fehlende Zugriff auf NFS ist und bleibt ein NOGO!
Da ist es schon mehr als interessant, dass ich zufällig auf der Suche nach einer aktuellen SW Version des Raw Converters rawtherapee war, die mir als AppImage auf der Produkthomepage angeboten wurde.
Ein AppImage ist eine einzige Datei, die das Program, die Resourcen und alle Abhängigkeiten beinhaltet. Man kopiert sie in auf den lokalen Rechner (bevorzugt dort, wo die $PATH Umgebung schon Programme erwartet, bspw.
/usr/local/bin ~/bin
und führt sie aus. Das Konzept scheint den Apps auf macOS zu ähneln, auch wenn es dort technisch gesehen ein Dateiordner ist, der im Finder als singuläre Datei angezeigt wird.
Was sofort bleibt ist die Frage der Linux Desktop Integration. Diese wird beim Programmstart (Klick im Dateibrowser oder Konsolenaufruf) folgendermaßen beantwortet:
Dialog for integrating AppImage into Linux Desktop
Der Programmstart überprüft diese und stellt sie ggf. sicher – clever! Was noch bleibt ist die Frage der Deinstallation. Das AppImage löschen ist kein Problem, was passiert aber mit der existierenden Desktop Integration? Diese muss mit einem Kommandobefehl erfolgen, der im Beispiel des Programs rawtherapee folgendermaßen aussieht:
VideoLanClient wird wie eine steigende Anzahl weiterer SW Pakete auf Ubuntu standardmäßig als snap package installiert.
Von Vorteil ist natürlich die laufenden SW Aktualisierungen, da das vlc snap package in sich geschlossen ist (self contained) und die typischen Abhängigkeiten mitbringt. Gerade im Video Playback Bereich kann dies, bedingt durch unzählige Codecs, von Vorteil sein.
Umso enttäuschender ist das Verhalten des snap packages, wenn man versucht ein Video aus einem NFS share zu starten, was VLC mit einer Fehlermeldung quittiert.
Der Grund dafür ist das Rechtemodell der snaps und das self contained Modell, das dazu führt, dass die Applikation wie in einer chroot Umgebung nicht das eigentliche root filesystem des Rechners sehen kann.
Zwar können sich snap packages via connections allerhand Zusatzrechte besorgen, z.B.
home – erlaubt Zugriff unterhalb von /home
removable-media – erlaubt Zugriff unterhalb von /media
..ein Zugriff auf /mnt oder /net oder gar wahlfreier Zugriff auf einen Order im eigentlich root filesystem ist nicht vorhergesehen. Dies gilt für alle snaps, die nicht im sog. classic mode verfügbar sind.
Wichtig hierbei ist die Angabe des confinement Parameters des snap packages, was man mit folgendem Befehl untersuchen kann:
snap info vlc --verbose
Falls das confinement auf strict gesetzt ist, können nur die durch das package gesetzten connections benutzt werden. Falls devmode auf true gesetzt wird – eine Operation die durch den Benutzer möglich ist – können zwar alle connections durch diesen gesetzt werden, was aber für den NFS Zugriff nichts bringt, da eine solche connection nicht vorgesehen ist. Einzige Abhilfe ist ein snap package mit einem confinement, welches auf classic gesetzt wurde um die connections komplett zu umgehen und einen Zugriff analog der normalen (.deb) packages zu erlauben. Das snap package atom macht genau dies.
