Selbstkompilierte Software hat einen Nachteil: Ob sie sich später sauber deinstallieren lässt, hängt von der eigenen Disziplin ab. Zum Glück lässt sich der nachhelfen.

Wer ausschließlich für die jeweilige Distribution vorkompilierte rpm– oder deb-Pakete mit dem vorgesehenen Paketmanager installiert, tut dies im Bewusstsein, sie bei Bedarf auf gleichem Wege auch wieder rückstandslos entfernen zu können. Selbst wenn “Leichen” auf dem System verbleiben, bleibt immer noch das gute Gefühl der eigenen Unschuld: In dem Fall hat der Paket-Packer schlampig gearbeitet.

Doch selbst softwaremäßig gut bestückte Distributionen müssen irgendwann passen: Nicht jedes nützliche Programm gibt es für alle Distributionen und Distributionsversionen fertig vorkonfektioniert. Sobald es “Selbstkompilieren” heißt, kommt spätestens beim make install die Stunde der Wahrheit: Wer hier nicht genauestens Buch führt, findet zwar sicherlich das installierte Binary und eventuell auch die entsprechende Manpage wieder, doch war das tatsächlich alles, was dieses unscheinbare Kommando, mit root-Rechten ausgeführt, in den Weiten des Dateisystems versteckt hat?

Arbeitsverbot für make

Immerhin gibt es auch zu make eine Manpage, und die erklärt, dass die Option -n alle Kommandos auflistet, die während der Abarbeitung des Makefile zum Zuge kommen, jedoch auf deren Ausführung verzichtet. Kein Problem, solange diese Liste einfach und übersichtlich ist wie beim mirror-Paket:

pjung@chekov:~/software/mirror$ make -n install[…]
install -m 755 -g gnu mirror.pl /usr/local/sbin/mirror[…]

Hier wird lediglich das install-Kommando aufgerufen, das die Datei mirror.pl ins Zielverzeichnis /usr/local/sbin kopiert und gleichzeitig in mirror umbenannt. Dort bekommt sie dank der Modus-Option -m 755 die Rechte rwxr-xr-x und wird mit -g der Gruppe gnu (die bereits vorhanden sein muss) zugeordnet.

Kopiert man die von make install auszuführenden Kommandos mit dem Umleitungsoperator > in eine zu archivierende Datei (make -n install > dateiname), kann man bei späteren Deinstallationsanwallungen den Installationsprozess rekonstruieren und /usr/local/sbin/mirror und Konsorten per Hand mit dem rm-Kommando aus dem System entfernen.

Sobald make install jedoch längliche, hochkomplexe Shell-Skripte ausführen soll, die ihrerseits wieder auf im Quellpaket mitgelieferte Skripte zurückgreifen, reicht der Wille zur Disziplin sicherlich nicht mehr aus. Ein anderer Ansatz muss her.

Jedem das seine Verzeichnis

Die einfachste Lösung wäre, jede selbstkompilierte Software in einem jeweils eigenen Verzeichnis unterzubringen. Der “Filesystem Hierarchy Standard” (http://www.pathname.com/fhs/) schlägt hier /opt/Paketname für “add-on application software packages”, zusätzliche Anwendersoftware, vor. Sinnvoll ist jedoch auch die Alternative eines Paketverzeichnisses unterhalb von /usr/local, selbst wenn dies im FHS nicht vorgesehen ist.

In diesem Paketverzeichnis sollte dann wieder eine typische Unix-Verzeichnishierarchie mit bin-Verzeichnis für User-Programme, sbin für der Systemverwalterin root vorbehaltene Binaries, man für Manpages, lib für Bibliotheken, include für eventuelle Header-Files etc. angelegt werden, soweit das jeweilige Softwarepaket passende Dateien mitbringt.

Doch wie überzeugt man make install, in solch ein Verzeichnis hineinzukopieren? Anscheinend, indem man die Datei makefile oder Makefile modifiziert. Eine Sicherheitskopie angelegt, gilt es, nach dem Target (“Ziel”) install zu suchen. Das Makefile bestimmt nämlich, mit welchen Argumenten make aufgerufen werden kann: Nur Wörter, die darin am Anfang einer Zeile stehen und von einem Doppelpunkt beendet werden, sind erlaubt. Das makefile aus dem mirror-Paket ist recht übersichtlich:

install:[…]
        install -m $(EXMODE) -g $(GRP) mirror.pl $(BINDIR)/mirror[…]

Hier finden wir, von genau einem Tabulatorzeichen eingerückt, die von make install auszuführenden Kommandos wieder – allerdings sind konkrete Werte durch Variablen ersetzt. Ein Vergleich zeigt, dass $(BINDIR) offensichtlich den Inhalt der Variablen BINDIR an dieser Stelle einfügt, und BINDIR bekommt einige Zeilen weiter oben den Wert /usr/local/sbin zugewiesen:

# directory to install public executables
BINDIR = /usr/local/sbin

Wollen wir das “Verzeichnis, in dem öffentlich zugängliche ausführbare Dateien” abgelegt werden, in /opt/mirror/sbin ändern, verlangt das lediglich eine Korrektur im makefile:

BINDIR = /opt/mirror/sbin

Die Herausforderung bei dieser Verfahrensweise besteht lediglich darin, alle Variablen herauszufinden, die sich auf den Installationsschritt beziehen. Das kann in Friemelarbeit ausarten, bei der viele Kontrollläufe in Form von make -n install nötig werden. Bei solchen handgeschriebenen Makefiles kommt es auch des Öfteren vor, dass der Autor nicht sauber gearbeitet und “versehentlich” statische Pfadangaben mit eingebaut haben. Hier hilft nur die konsequente Suche nach der hartnäckigen Verzeichnisangabe.

Ein Problem kommt hinzu: Wenn sich make install mit einer Fehlermeldung der Art

install: cannot create regular file `/opt/mirror/sbin': No such file or directory

beschwert, fehlt das Zielverzeichnis /opt/mirror/sbin, das per Hand angelegt werden muss. Fehlt nicht nur das letzte Unterverzeichnis sbin, sondern auch sein übergeordnetes Directory mirror, erspart man sich einen mkdir-Befehl, wenn man mit

mkdir -p /opt/mirror/sbin

alle nötigen Eltern-(“parent”-)Verzeichnisse mit einem Mal anlegt.

configure beim Wort genommen

Bei Softwareprojekten ab einer gewissen Größe wird es jedoch den meisten Autor(inn)en zu mühsam, das Makefile von Hand zu warten. Sie greifen auf automatische Makefile-Erzeugungsmechanismen zurück. Der Nachteil dabei: Das Makefile wird sehr komplex – ein Grund, warum make -n install schwer zu entziffern wird.

Dem steht der Vorteil gegenüber, dass sich das Makefile-Erstellungstool durchaus beeinflussen lässt. Wenn etwa das mitgelieferte configure-Skript einer Software ihren Namen zu Recht trägt, sollte sich hier auch einstellen lassen, wohin die fertig erstellten Dateien hinkopiert werden sollen.

pjung@chekov:~/software/sylpheed-0.6.5$ ./configure --help | less
Usage: configure [options] [host]
Options: [defaults in brackets after descriptions]
Configuration:
  --cache-file=FILE       cache test results in FILE
  --help                  print this message[…]
Directory and file names:
  --prefix=PREFIX         install architecture-independent files in PREFIX
                          [/usr/local][…]
Features and packages:[…]
  --enable-ssl            Enable SSL support using OpenSSL [default=no][…]

Tatsächlich spricht configure auf die gängige Hilfeoption –help an – Listing 1 zeigt Ausschnitte aus der Hilfestellung zum configure-Skript des Mailprogramms sylpheed[2]. Mit diesen Informationen ausgestattet, sorgen wir per

./configure --cache-file=/tmp/sylpheed.tests --prefix=/opt/sylpheed --enable-ssl

dafür, dass SSL-Unterstützung eingebaut und sämtliche Dateien bei der Installation mit make install unterhalb von /opt/sylpheed abgelegt werden. –cache-file erlaubt es, nach dem Gleichheitszeichen eine Datei anzugeben, in denen die von configure gefundenen Testergebnisse gespeichert werden. Normalerweise ist das config.cache im aktuellen Verzeichnis – hier haben wir stattdessen /tmp/sylpheed.tests gewählt.

Wer jetzt hergeht und im erstellten Makefile Änderungen vornimmt, tut dies übrigens mit Netz und doppeltem Boden: Sollten sich händische Korrekturen als falsch erweisen, genügt es, statt des ganzen configure-Rattenschwanzes ./config.status zu sagen. In dieser ausführbaren Datei ist genau gespeichert, was getan werden muss, um wieder zum selben Ergebnis zu kommen wie beim letzten configure-Lauf.

Ein make kompiliert die Software, während make install unterhalb des Präfix-Verzeichnisses einen ordentlichen Unix-Dateibaum anlegt und die zum Benutzen der Software nötigen Dateien hineinkopiert: Bei Sylpheed entsteht unterhalb von /opt/sylpheed ein bin-Unterverzeichnis, das das ausführbare Programm enthält, sowie ein share-Directory, das in weiteren Unterverzeichnissen das Online-Handbuch im HTML-Format bzw. die Lokalisierungsdateien enthält, die nötig sind, um das Programm mit deutschen oder anderssprachigen Benutzerdialogen auszustatten.

Da /opt/sylpheed/bin nicht im mit echo $PATH anzeigbaren Suchpfad liegt, schlägt ein einfaches sylpheed& fehl (oder startet ein Programm gleichen Namens, das in einem der im PATH aufgeführten Verzeichnisse zufällig bereits liegt). Erst bei Angabe des kompletten Pfads zum Binary…

/opt/sylpheed/bin/sylpheed&

… startet das neue Programm.

Abbildung 1: Erst der Shell-Befehl “(export LC_ALL=de_DE; /opt/sylpheed/bin/sylpheed)&” sorgt für ein deutschsprachiges Sylpheed

Wege erschließen

Kein Problem für denjenigen, der selten Software kompiliert. Mit einem

export PATH=$PATH:/opt/sylpheed/bin

lässt sich die PATH-Variable schnell und unkompliziert in einer Shell erweitern. Mit $PATH holt man sich den bisherigen Inhalt von PATH und hängt hinter einem Doppelpunkt das neue Suchverzeichnis an. Das Ergebnis wiederum weisen wir PATH als neuen Wert zu. export sorgt dafür, dass die Bash die Variable an “Kindprozesse” weitergibt, etwa an eine konsole, die per konsole & aus der aktuellen Shell gestartet wird.

Sollten Sie jedoch bereits im alten Pfad ein sylpheed-Binary gefunden haben, hilft diese Neusetzung herzlich wenig, denn die Shell nimmt immer die Datei, die sie zuerst findet. Setzt man bei der Pfadneuzuweisung hingegen /opt/sylpheed/bin vor alle bisherigen Suchverzeichnisse, …

export PATH=/opt/sylpheed/bin:$PATH

… dreht sich der Spieß um, und das bislang ohne Verzeichnisangabe gefundene Binary muss nun explizit mit Pfad aufgerufen werden.

Doch wer will schon jedes Mal den Pfad ändern, wenn er/sie ein Programm aus einem “Nicht-Standard”-Verzeichnis benötigt? Sollen alle Benutzer/innen des Rechners etwas von der Pfaderweiterung haben, empfiehlt es sich, die Änderung von root in die systemweite Konfigurationsdatei /etc/profile einzutragen. (Manche Distributionen wie SuSE lesen auch speziell für lokale Änderungen gedachte Dateien wie /etc/profile.local ein.)

Soll die Pfadergänzung nur für das eigene Benutzerkonto gelten (sinnvoll etwa für Software, die man im eigenen Home-Verzeichnis – etwa unter ~/bin – installiert hat), so sind die persönlichen Startdateien der Shell (für die bash~/.bashrc und ~/.bash_profile) Korrekturkandidaten.

Keine neuen Pfade

Wer viel selbst kompiliert, wird die ständige Pfadkorrektur schnell leid – zumal ein vielzeiliges PATH-Monster nicht mehr gut zu überschauen ist. Wie gut, dass es Alternativen gibt. Links sorgen in einem Linux-/Unix-Dateisystem dafür, dass eine Datei unter mehreren Namen ansprechbar ist. Statt etwa das sylpheed-Binary aus /opt/sylpheed/bin in das (meist schon im Suchpfad vorhandene und für lokale Dateien gedachte) Verzeichnis /usr/local/bin zu kopieren und es somit doppelt vorrätig zu haben, reicht ein “symbolischer Link” …

ln -s /opt/sylpheed/bin/sylpheed /usr/local/bin/sylpheed

… aus, um das Binary unter beiden Angaben zugänglich zu machen.

Für eher kleine Programme wie Sylpheed reicht das aus – doch wehe, man hat es mit größeren Softwarepaketen zu tun, die mehrere Binaries erzeugen, viele Manpages dabei haben und im schlimmsten Fall auch noch eigene Libraries mitbringen. So viele Links will wohl niemand von Hand setzen und schon gar nicht wieder entfernen, wenn /opt/sylpheed dem Deinstallator rm -rf /opt/sylpheed zum Opfer fiel. Zwar kann das Progrämmchen symlinksbroken links, die ins Nichts zeigen, aufstöbern und löschen, doch dieses nützliche Tool [3] ist auf eher wenigen Systemen vorinstalliert.

Da können wir uns auch gleich auf die Suche nach einem Tool begeben, das die gesamte Linkverwaltung für uns übernimmt. Debian-User haben es gut, denn diese Distribution enthält mit stow [4,5] ein entsprechendes Progrämmchen.

apt-get install stow

lädt das entsprechende Paket (Netzzugang vorausgesetzt) automatisch herunter und installiert es sofort, sofern root das Kommando aufruft.

Doch auch Benutzer/innen anderer Distributionen müssen nicht verzweifeln. Jegliche Debian-Software lässt sich von einem Debian-Mirror nicht nur als vorkompiliertes .deb-Paket, sondern auch als Original-Tarball des Software-Autors herunterladen [5]. Die Debian-Download-Seiten im Web (Abbildung 2) bieten im unteren Teil unter dem Punkt Source Code: jeweils drei Links an: die Paketbeschreibung als dsc-formatiertes ASCII-File, das originale tar.gz-Quellarchiv und der Source-Code der Änderungen, die der Debian-Paketbauer ins Binärpaket eingebaut hat, als mit gzip gepackte diff-Ausgabe [6].

Abbildung 2: Debian liefert immer den Original-Sourcecode mit

Das Tarfile packt man wie gewohnt mit tar -xzvf Archivdatei aus (die Option -z entpackt die gzip-Komprimierung, -x extrahiert den Inhalt, -v sorgt für etwas mehr Gesprächigkeit bei tar (englisch: “verbose”), und -f Archivdatei gibt an, welches File aufgedröselt werden soll). Mit

./configure --prefix=/opt/stow

im Verzeichnis stow-1.3.2.orig konfigurieren wir auch stow mit einem eigenen Zielverzeichnis /opt/stow. Auf make können wir ausnahmsweise verzichten, da es in diesem Fall eines Perl-Skripts ausnahmsweise nichts zu kompilieren gibt. make install sorgt dann für eine Dateistruktur wie in Abbildung 3.

Abbildung 3: Mit dem Präfix /opt/stow entsteht für stow eine eigene Verzeichnishierarchie

Versteckte Schätze

Jetzt ist stow zwar installiert, aber ein wenig Dokumentation wäre nicht schlecht. Zwar liegt eine info-Datei in /opt/stow/info, aber wer bislang noch nichts mit diesem Informationssystem zu tun hatte, wird mit

info -f /opt/stow/info/stow.info

nicht so recht glücklich (Abbildung 4; Grundlagen der Bedienung des info-Programms bietet übrigens die Rubrik “Zu Befehl” in dieser Ausgabe). Auf dem Wunschzettel steht eine HTML-Datei, die sich im Browser ansehen und nett formatiert ausdrucken lässt.

Abbildung 4: Infos mit info

Tatsächlich enthält das Makefile in stow-1.3.2.orig ein paar nützliche Geheimnisse: Auch wenn wir keine stow-Entwickler/innen sind, lassen wir uns vom Kommentar

# The rules for manual.html and manual.texi are only used by
# the developer

nicht abschrecken und merken uns das verheißungsvolle Make-Target manual.html, das im Anschluss daran definiert ist:

manual.html: manual.texi
        -rm -f $@
        texi2html -expandinfo -menu -monolithic -verbose $<

Dass make in diesen Regeln angewiesen wird, darauf zu achten, dass die Regeln des (später definierten) Targets manual.texi ausgeführt wurden, bevor die eigenen (mit Tabulator eingerückten) Befehle zum Zuge kommen, besagt die erste Zeile. Die erste echte Aktion des manual.html-Targets besteht darin, eine etwa vorhandene Datei gleichen Namens ($@ steht für das Target selbst, also das, was in der nicht eingerückten Zeile vor dem Doppelpunkt steht) mit rm -f (“force”, also “mit aller Macht”) zu löschen. Sollte es dabei eine Fehlermeldung geben (etwa weil keine Datei manual.html existiert), soll make schweigen – daher das Minus vor dem rm-Befehl.

Wirklich interessant für uns ist aber die zweite Regel: Das texi2html-Programm ist laut seiner Manpage ein “Texinfo-nach-HTML-Konverter”. Da $< in der Make-Syntax für das steht, was nach dem Target-Namen und seinem Doppelpunkt steht, wird schnell klar: Dieses Target produziert eine HTML-Datei aus einer (vom manual.texi-Target erzeugten) Datei namens manual.texi.

Der texi2html-Manpage wiederum entnehmen wir, dass dieses Programm, sofern es mit der -monolithic-Option aufgerufen wird, aus einer Texinfo-Datei namens foo eine einzelne Datei foo.html erzeugt (statt Fußnoten und Inhaltsverzeichnisse in zusätzliche, eigene Dateien auszulagern).

Der Befehl make manual.html im stow-Quellverzeichnis sieht also ganz so aus, als ob es uns unseren Wunsch nach einer stow-Handbuch in HTML-Form erfüllt. Tatsächlich liegt anschließend ein brauchbares manual.html im aktuellen Verzeichnis (Abbildung 5).

Abbildung 5: Lohn eines “make manual.html”

Wie es sein sollte

Um stow erfolgreich einsetzen zu können, gilt es, einige Begrifflichkeiten zu klären. Wenn in der Dokumentation vom stow directory die Rede ist, haben wir es mit dem Verzeichnis zu tun, in dem die Verzeichnisse mit den Dateihierarchien der einzelnen, kompilierten Softwarepakete liegen. Anders ausgedrückt, geht die Vorarbeit für die stow-Nutzung dahin, beim configure-Lauf für ein Softwarepaket jeweils das Präfix Stow-Verzeichnis/Paketname anzugeben. In unserer Planung trägt das Stow-Verzeichnis also den schlichten Namen /opt.

Als nächste Information muss stow wissen, in welche Verzeichnishierarchie hinein es die Inhalte von Stow-Verzeichnis/Paketname verlinken soll. Als target directory eignet sich /usr/local hervorragend, zumal dann, wenn /usr/local/bin bereits im PATH enthalten ist.

Mit den Optionen -t und -d lassen sich Zielverzeichnis und Stow-Verzeichnis angeben, letztere Option kann auch wegfallen, wenn wir uns mit cd /opt ins Stow-Verzeichnis begeben.

Noch müssen wir /opt/stow/bin/stow selbst ordentlich nach /usr/local/bin/stow verlinken, ehe wir es als ohne Pfadangabe aufrufen können. Ein

/opt #./stow/bin/stow -v -v -v -n -t /usr/local stow
Stowing package stow…
Stowing contents of stow
Stowing directory stow/bin
Stowing contents of stow/bin
LINK /usr/local/bin/stow to ../../../../opt/stow/bin/stow
Stowing directory stow/info
LINK /usr/local/info to ../../../opt/stow/info

gibt uns die Kontrolle darüber, was mit dem Inhalt des Verzeichnisses stow passieren würde, wenn wir ihn nach /usr/local verlinken wollten: Die Option -n sorgt einstweilen dafür, dass nichts geschieht, während jedes -v (“verbose”) das Programm etwas geschwätziger macht; allerdings ist bei Plauderlevel 3 Schluss.

Sofern Verzeichnisse, die unterhalb von ./stow zu finden sind, in /usr/local bislang noch nicht existieren (im Beispiel /usr/local/info), legt das Programm ./stow/bin/stow sie nicht etwa an, sondern macht es sich einfach: /usr/local/info verweist auf /opt/stow/info. Existiert das jeweilige Directory schon (im Beispiel bei /usr/local/bin der Fall), setzt stow darin einen Link auf die entsprechende Datei (/usr/local/bin/stow zeigt auf /opt/stow/bin/stow). Für die Quelldatei gibt stow relative Pfade ausgehend vom Zielverzeichnis an.

Das sieht vernünftig aus, also machen wir mit ./stow/bin/stow -v -t /usr/local stow Nägel mit Köpfen und schauen uns das Ergebnis an:

/opt # ls -Al /usr/local
insgesamt 3
drwxr-xr-x 2 root root  55 Nov 26 20:02 bin
drwxr-xr-x 2 root root 150 Nov 26 18:28 ftp
lrwxrwxrwx 1 root root  22 Nov 26 20:02 info -> ../../../opt/stow/info
drwxr-xr-x 2 root root  57 Nov 26 18:28 man

Der Ärger mit den Bugs

Doch ehe wir jetzt voller Euphorie damit beginnen, weitere Software zu verstauen, prüfen wir doch besser erst einmal nach, ob die versprochene Deinstallation mit der Option -D tatsächlich so einfach ist. Wenn /usr/local/bin im Suchpfad liegt, können wir stow jetzt auch ohne Verzeichnisangabe aufrufen:

/opt # stow -v -v -v -n -D -t /usr/local stow
Unstowing in /usr/local
Unstowing in /usr/local/bin
Unstowing in /usr/local/ftp
Unstowing in /usr/local/ftp/bin
Unstowing in /usr/local/ftp/dev
Unstowing in /usr/local/ftp/etc
Unstowing in /usr/local/ftp/lib
Unstowing in /usr/local/ftp/usr
Unstowing in /usr/local/ftp/usr/bin
Unstowing in /usr/local/ftp/msgs
Unstowing in /usr/local/man

Das sieht komisch aus – warum wird /usr/local/info nie erwähnt? Warum steht da nichts davon, dass /usr/local/bin/stow gelöscht werden soll? Und was hat stow in Unterverzeichnissen wie man und ftp verloren, in die es gar nichts verlinkt hat?

Mutige sichern jetzt die komplette /usr/local-Hierarchie und lassen stow -D nochmals ohne die -n-Option laufen. Doch auch davon wird es nicht besser:

/opt # ls -al /usr/local/bin
insgesamt 16
lrwxrwxrwx 1 root root  29 Nov 26 20:02 stow -> ../../../../opt/stow/bin/stow

Der Links sind immer noch da …

Soviel wir auch hin- und herprobieren, irgendwann heißt es, in den sauren Apfel zu beißen und sich einzugestehen: stow ist fehlerhaft und ungenügend getestet. Wirklich funktionieren will es nur, wenn das Stow-Directory mit den Paketunterverzeichnissen ein Unterverzeichnis des Zielverzeichnisses ist.

Wie gut, dass wir noch wissen, was verlinkt wurde:

/opt # rm /usr/local/info
/opt # rm /usr/local/bin/stow

Legen wir also ein neues Stow-Verzeichnis stow unterhalb von /usr/local an und packen unser stow-Paketverzeichnis dahin:

/opt # mkdir /usr/local/stow
/opt # mv stow /usr/local/stow/

Verstauen

Der Vorteil des neuen Stow-Directories: Wir müssen das Target-Verzeichnis /usr/local nicht mehr mit angeben:

/usr/local/stow # ./stow/bin/stow -v stow
Stowing package stow…
LINK /usr/local/bin/stow to ../stow/stow/bin/stow
LINK /usr/local/info to stow/stow/info

verlinkt ordentlich, und auch die Deinstallation sieht vernünftig aus:

/usr/local/stow # stow -v -D stow
UNLINK /usr/local/bin/stow
UNLINK /usr/local/info
UNLINK /usr/local/bin/stow
RMDIR /usr/local/bin

Links werden entfernt und nunmehr leere Verzeichnisse wie /usr/local/bin gelöscht. Nach der Wiederverlinkung von stow zeigt /usr/local/bin als neuangelegter Link auf /usr/local/stow/stow/bin.

Um nun auch sylpheed sauber zu installieren, müssen wir das Mailprogramm allerdings mit neuem Präfix /usr/local/stow/sylpheed neu konfigurieren und kompilieren, ehe stow nach einem make install seinem Verlinkungswerk nachgehen kann:

/usr/local/stow # stow -v sylpheed
Stowing package sylpheed…
UNLINK /usr/local/bin
MKDIR /usr/local/bin
LINK /usr/local/bin/stow to ../stow/stow/bin/stow
LINK /usr/local/bin/sylpheed to ../stow/sylpheed/bin/sylpheed
LINK /usr/local/share to stow/sylpheed/share

… und für eine angenehme Überraschung sorgt:

/usr/local/stow # ls -al /usr/local/bin
insgesamt 0
lrwxrwxrwx    1 root     root           21 Nov 26 20:13 stow -> ../stow/stow/bin/stow
lrwxrwxrwx    1 root     root           29 Nov 26 20:13 sylpheed -> ../stow/sylpheed/bin/sylpheed

Plötzlich ist /usr/local/bin kein Symlink auf das bin-Verzeichnis des stow-Pakets mehr, sondern ein ordentliches Directory, in dem zwei neue Symlinks zu finden sind: Das stow-Programm wurde nach der Auflösung des alten Links auf /usr/local/stow/stow/bin einfach eigenständig verlinkt. Sollte es uns nun danach gelüsten, sylpheed wieder loszuwerden, rollt sich alles wieder sauber zurück:

/usr/local/stow # stow -v -D sylpheed
UNLINK /usr/local/bin/sylpheed
UNLINK /usr/local/share
UNLINK /usr/local/bin/stow
RMDIR /usr/local/bin
LINK /usr/local/bin to stow/stow/bin
/usr/local/stow # ls -al /usr/local/bin
lrwxrwxrwx 1 root root 13 Nov 26 20:14 /usr/local/bin -> stow/stow/bin

Ein rm -rf /usr/local/stow/sylpheed sorgt dann dafür, dass (außer persönlichen Mail- und Konfigurationsdateien) wirklich keine Rückstände mehr auf dem System verbleiben.