GNU Stow

In diesem Artikel soll GNU Stow vorgestellt werden, welches eine einfache Möglichkeit bietet, eine Datei- und Verzeichnisstruktur per symbolische Verknüpfungen in einem anderen Verzeichnis zur Verfügung zu stellen. Das hört sich jetzt vermutlich erst einmal unverständlich an, aber das wird sich hoffentlich gleich legen. Das Tool unterliegt der GPLv3 und findet sich, wie der Name schon verdeutlicht, unter dem Dach des GNU-Projektes wieder.

Die Wahrscheinlichkeit, dass auch die Distribution eurer Wahl ein Paket anbietet, dürfte sehr hoch sein, ist dies doch zum Beispiel bei Ubuntu, Debian, Archlinux und Suse Leap der Fall. Der Autor selbst hat GNU Stow unter Archlinux wie unter Debian 11 im Einsatz. Ursprünglich wurde das Tool geschrieben, um Programme besser verwalten zu können, die nicht mit dem Paketmanager installiert wurden, wie zum Beispiel selbst kompilierte Programme. Neben diesem ursprünglichen Anwendungsfall kann man mit dem Tool auch seine Konfigurationsdateien ("dotfiles") verwalten oder seine Skripte.

Verwaltung von Drittprogrammen

Bei Linux wird das Ergebnis von selbst kompilierten Programmen in der Regel unter /usr/local abgelegt. Das Problem an dieser herkömmlichen Vorgehensweise ist, dass das Entfernen eines Programmes dadurch problematisch werden kann. Dies ist dann der Fall, wenn im Zuge des händischen Installierens nicht nur eine einzelne Datei unterhalb von /usr/local/bin angelegt wurde, sondern mehrere Dateien in anderen Verzeichnissen wie unter /usr/local/lib, /usr/local/share, usw.

GNU Stow erleichtert das Entfernen in solchen Fällen ungemein. Zugegebenermassen kann man natürlich die Frage stellen, ob dies in Zeiten von Flatpak und AppImages überhaupt noch von Relevanz ist. Diese können aber nicht immer nutzbar sein. Mögliche Gründe hierfür:

• Es gibt für das Programm kein FlatPak oder AppImage
• Es gibt dies nicht für eine bestimmte benötigte Version, zum Beispiel für die derzeitige Entwicklungsversion.
• Man benötigt Features, die im Programm nur beim Setzen bestimmter Flags beim Kompilieren zur Verfügung stehen und diese waren beim Erstellen des Anwendungscontainers nicht gesetzt.
• Man möchte selbst Änderungen am Source-Code vornehmen.
• Man will - aus welchen Gründen auch immer - dafür kein Container-Format verwenden.

Ok, genug gefaselt, machen wir mal ein kleines Beispiel. Nehmen wir an, wir möchten unter Debian neovim 0.7.2 verwenden, das nicht in den Repositories vorhanden ist. Dazu klonen wir das Repository und bauen uns das Projekt.

git clone https://github.com/neovim/neovim.git
git checkout v0.7.2
cd neovim
make CMAKE_BUILD_TYPE=Release

Ein einfaches

sudo make install 

würde nun einiges an Dateien in die entsprechenden Verzeichnisse unterhalb von /usr/local kopieren, was das spätere Entfernen erschweren würde. Also legen wir uns zunächst ein Hilfsverzeichnis an

sudo mkdir -p /usr/local/opt/neovim

In dieses installieren wir neovim mittels

sudo make CMAKE_INSTALL_PREFIX=/usr/local/opt/neovim install

find /usr/local/opt/neovim -type f | wc -l

gibt uns als Ergebnis dann 1608 aus; also wenn wir neovim mit dem einfachen

sudo make install

nach /usr/local installiert hätten und wieder entfernen wollen würden, müssten wir uns darum bemühen, 1608 Dateien aus dem Dateisystem händisch zu löschen. (Zugegebenermassen würde dies in diesem Beispiel sogar noch ohne
grosse Probleme gehen, da entweder der Verzeichnispfad oder der Dateiname "nvim" beinhaltet.)

Aber wir haben ja die Installation extra in ein Hilfsverzeichnis vorgenommen, dessen Inhalt wir jetzt mit stow nach /usr/local/ verknüpfen können. Der Befehl hierzu lautet

stow /usr/local/opt/neovim -t /usr/local

Dann wird stow für jede Datei oder Verzeichnis unter /usr/local/opt/neovim einen Symlink unter /usr/local anlegen.
Wenn wir nun neovim entfernen möchten, können wir dies auch wieder mit stow vornehmen:

stow /usr/local/opt/neovim -t /usr/local

Das kann zum Beispiel immer dann der Fall sein, wenn wir eine neue Version installieren möchten.

Als weiterer Vorteil bietet uns stow eine zusätzliche Sicherheit dadurch, dass es keine Verlinkung erzeugt, sondern einen Fehler anzeigt, wenn im Zielverzeichnis schon eine Datei mit demselben Namen existieren sollte. (Verzeichnisse hingegen werden einfach wiederverwendet, daher ist es auch kein Problem, dass /usr/local/bin schon existiert.)

Skripte

Selbstgeschriebene Skripte können ebenfalls auf diese Weise nach /usr/local/bin oder ~/bin verknüpft werden, während sie selbst an anderer Stelle in einem unter Versionsverwaltung stehenden Ordner liegen. Dies ist dann beispielsweise sinnvoll, wenn man seine Skripte in mehrere Git-Repos sortiert hat oder man die Skripte zwar in einem Repo, aber zur besseren Übersichtlichkeit in mehrere Unterordner aufgeteilt hat.

Ein Hinweis sei an dieser Stelle gegeben. Falls ihr nach /usr/local/bin verknüpfen wollt, solltet ihr auf eure Zugriffsrechte acht geben. Es kann aus sicherheitstechnischer Sicht eine schlechte Idee sein, wenn diese allzu leicht verändert werden können.

Verwaltung von Konfigurationsdateien

Eine weitere Möglichkeit des Einsatzes sind Konfigurationsdateien für einzelne Programme, die man gerne unter Versionsverwaltung stellen möchte. Dies kann nützlich sein, wenn man ein Programm auf verschiedenen Rechnern mit derselben Konfiguration verwenden möchte. Dies könnte die Konfiguration eurer Shell sein; sei es ~/.bashrc oder ~/.zshrc.

Es sei an dieser Stelle erwähnt, dass es hierfür Programme gibt, die speziell für diesen Anwendungsfall entwickelt wurden und dementsprechend mehr Möglichkeiten bieten. Ein Beispiel wäre Chezmoi, welches neben Linux auch Windows und MacOS unterstützt und es wohl ermöglicht, Transformationsregeln für die verschiedenen Plattformen zu hinterlegen.

Wer dies nicht benötigt, dem dürfte stow vermutlich ausreichen. An dieser Stelle sei auf die von mir allerdings nicht genutzte Option --dotfiles hingewiesen, welche es ermöglicht, die Konfigurationsdateien anders zu benennen, damit diese im Quellordner nicht mit einem Punkt beginnen und somit unsichtbar sind.

Fürderhin gibt es Kommandozeilenparameter, mit denen beim Verlinken Dateien ausgeschlossen werden können. Somit kann man seine zu verlinkenden Dateien direkt auf oberster Ebene ablegen und verhindern, dass Dateien und Verzeichnisse wie .git und .gitignore ebenfalls verlinkt werden.

Quelle: https://www.gnu.org/software/stow/