Für alle gängigen Distributionen gibt es fertige Paketversionen von Programmen, die sich komfortabel installieren lassen. Doch nicht selten hat man den Wunsch eine Software ins System einzubinden, wofür es noch keine fertigen Pakete gibt, wie beispielsweise Software in frühen Entwicklungsphasen (alpha, beta). Dann ist man gezwungen den Quelltext (Source Code) der Software händisch geführt in ausführbaren Code zu kompilieren.

Da Linux ein quelloffenes Betriebssystem ist, folgen auch die meisten Programme für dieses Betriebssystem diesem Paradigma. Das hat gleich mehrere Vorteile, welche sich zugegeben teilweise erst bei entsprechendem Sachverständnis ergeben:

• Jeder kann sich vor der Installation einer Software anschauen, was diese im System bewirkt
• Software im Quelltext ist distributionsunabhängig
• Software kann durch Modifikationen im Quelltext den jeweiligen Bedürfnissen angepasst werden

Dem gegenüber steht allerdings der Mehraufwand bei der Installation und ggf. Deinstallation der Software. Letzteres, da hier standardmäßig keine Verwaltungsinstanz eine automatische und saubere Deinstallation ermöglichen würde. Dieses Manko lässt sich aber durch einige Workarrounds weitestgehend beheben. Die gesamte Prozedur der Installation und Deinstallation soll deshalb an einem Beispiel genauer erläutert werden. Dazu soll der Mediaserver Mediatomb installiert werden. Projektseite

Im ersten Schritt muss sichergestellt werden, dass auf dem System einige Minimalvoraussetzungen erfüllt sind sind. Dazu zählen im Wesentlichen:

• gcc (GNU Compiler Collection)
  Compilersammlung für die gängigsten Programmiersprachen
• make
  Programm zum steuern des Übersetzungsprozesses
• svn (Subversion; optional)
  Programm zur Versionsverwaltung

Diese Programme, von denen möglichst immer die aktuellste Version bezogen werden sollte, befinden sich fast immer in Entwicklungspaketen (*-dev, *-devel) der verschiedenen Distributionen und werden selten standardmäßig mitinstalliert. Eine Suche mit Hilfe des jeweiligen Paketmanagers sollte aber schnell zu einem Ergebnis führen. Zudem sind zumindest die ersten beiden nicht nur für dieses Beispiel zu beschaffen, sondern werden generell beim Kompilieren benötigt!

Schließlich ist natürlich auch noch die neue Software selbst erforderlich. In diesem Fall der Mediaserver Mediatomb. Entscheidet man sich für die aktuelle Release-Version, ist diese über einen Downloadlink zu beziehen. Diese liegt, wie meist üblich für Software in Quelltext-Form, als *.tar.gz vor. Eine weitere oft verwendete Komprimierung für ein Archiv ist *.tar.bz2.

Entscheidet man sich für die aktuelle Testversion, so ist diese nur über Subversion verfügbar. Subversion ist eine Verwaltungssoftware zur Versionskontrolle und bietet dem Entwickler viele Möglichkeiten um den Softwarestatus zu managen. Für Anwender bietet es den Vorteil sich über definierte URLs über den Status von Software zu informieren und diese komfortabel zu beziehen.

Für den Download werden noch beide Versionen behandelt. Bei der weiteren Konfiguration und dem Kompilieren wird nur noch die Release-Version durchgenommen, da sich das Verfahren ab dem vorliegen des Quelltextes nicht unterscheidet.

Zu Beginn wechselt man in das Heimatverzeichnis und lädt das gepackte Archiv mit dem Standard Programm für den Dateidownload wget herunter:

wget http://downloads.sourceforge.net/mediatomb/mediatomb-0.11.0.tar.gz

--18:48:38--  http://downloads.sourceforge.net/mediatomb/mediatomb-0.11.0.tar.gz
 => `mediatomb-0.11.0.tar.gz'
Auflösen des Hostnamen »downloads.sourceforge.net«.... 216.34.181.59
Verbindungsaufbau zu downloads.sourceforge.net|216.34.181.59|:80... verbunden.
HTTP Anforderung gesendet, warte auf Antwort... 302 Found
Platz: http://surfnet.dl.sourceforge.net/
                       project/mediatomb/MediaTomb/0.11.0/mediatomb-0.11.0.tar.gz [folge]
--18:48:38--  http://surfnet.dl.sourceforge.net/
                       project/mediatomb/MediaTomb/0.11.0/mediatomb-0.11.0.tar.gz
 => `mediatomb-0.11.0.tar.gz'
Auflösen des Hostnamen »surfnet.dl.sourceforge.net«.... 130.59.138.21
Verbindungsaufbau zu surfnet.dl.sourceforge.net|130.59.138.21|:80... verbunden.
HTTP Anforderung gesendet, warte auf Antwort... 200 OK
Länge: 1.059.429 (1.0M) [application/x-gzip]

100%[=============================================>] 1.059.429     87.61K/s    ETA 00:00

18:48:49 (104.20 KB/s) - »mediatomb-0.11.0.tar.gz« gespeichert [1059429/1059429]

Nun kann das Archiv entpackt werden, wobei automatisch ein Ordner mit dem Quelltext angelegt wird:

tar -xzvf mediatomb-0.11.0.tar.gz

Damit wäre der Quelltext schon beschafft und bereit zur weiteren Verarbeitung.

Zum Vergleich der beiden Bezugsvarianten wird aber nun noch der Vorgang mit Subversion vollzogen. Wer möchte, kann vor dem Herunterladen einige der Optionen von Subversion testen:

• list
  Auflisten des Projektverzeichniss ohne es herunterzuladen
• info
  Projektinformation zur aktuellsten Version
• log
  Versions-History der einzelnen Versionen

Das Herunterladen selbst wir mit der Option co (checkout) durchgeführt:

svn co https://svn.mediatomb.cc/svnroot/mediatomb/trunk/mediatomb mediatomb_svn

A    mediatomb_svn/README.UTF_8
A    mediatomb_svn/devconf
A    mediatomb_svn/AUTHORS

...gekürzt...

A    mediatomb_svn/web/js/auth.js
A    mediatomb_svn/web/js/items.js
 U   mediatomb_svn
Ausgecheckt, Revision 2020.

Nachdem der gesamte Quelltext heruntergeladen wurde, sollten nun im Heimatverzeichnis die Release-Version im Verzeichnis mediatomb-0.11.0/ vorliegen und die aktuellste Testversion im Verzeichnis mediatomb_svn/. Falls mit der neusten Testversion keine umfangreichen Änderungen einher gehen, werden sich die Inhalte auf den ersten Blick kaum unterscheiden. Ebenso verhält es sich mit der weiteren Prozedur bis zur Installation der Software, weshalb, wie bereits erwähnt, ab jetzt nur noch mit der Release-Version gearbeitet wird. Daher wird nun in das Verzeichnis mediatomb-0.11.0/ gewechselt und der Inhalt genauer betrachtet.

In einem ordentlich erstellten Quelltext Archiv befinden sich unter anderem einig Dateinamen, die auffällig alle in Großbuchstaben geschrieben sind. Diese nicht standardisierte Konvention verweist darauf, dass es sich hierbei um Textdateien handelt. Für die Installation sind die Dateien README und/oder INSTALL von Interesse. Dort wird die gesamte Prozedur des Kompilierungsvorgangs genauer beschrieben.

Wie in den allermeisten Fällen wird auch hier auf die klassische Prozedur verwiesen:

1. ./configure
2. make
3. make install

Der Befehl ./configure führt ein Shellscript aus und bereitet den Quelltext auf die Kompilierung, also die Übersetzung in Binärcode vor. Dazu wird von dem Script versucht korrekte Werte für verschiedene systemabhängige Variablen zu ermitteln. Zudem bietet ein configure-Script oft noch weitere Optionen, mit denen sich die anschließende Übersetzung noch weiter individualisieren lässt. Ob und welche Optionen ein configure-Script bietet, ist durch die Option --help in Erfahrung zu bringen.

Sollte es während diesem Vorgang zu einem Problem kommen, bricht das Script ab und verweist auf die Datei config.log. Dort ist der bisherige Vorgang dokumentiert und man kann auch erkennen, welches Problem den Abbruch verursacht hat.

Anmerkung: Die folgend auftretenden Probleme sollen nicht abschrecken und sind sogar absichtlich provoziert worden, damit auch der Umgang mit Problemfällen angesprochen werden kann.

./configure

Daraufhin startet das Script, bricht aber nach einiger Zeit mit folgender Meldung ab...

...
checking sqlite3.h usability... no
checking sqlite3.h presence... no
checking for sqlite3.h... no
checking /usr/local/include/sqlite3.h usability... no
checking /usr/local/include/sqlite3.h presence... no
checking for /usr/local/include/sqlite3.h... no
checking for mysql_config... no
checking for mysql_config... no
mysql_config script not found
configure: error: Support of at least one of mysql or sqlite3 must be configured

Wie der Meldung zu entnehmen ist, fehlt anscheinend der Support für MySQL oder Sqlite3 auf dem System. Da mindestens eine dieser Datenbanken verfügbar sein muss, wird sich für die schlankere Variante Sqlite3 entschieden und versucht dem Problem auf den Grund zu gehen. Dazu bietet sich nun an die Log-Datei config.log nach diesem Begriff zu durchsuchen:

cat config.log |grep 'sqlite3'

configure:20010: checking sqlite3.h usability
conftest.cpp:161:21: error: sqlite3.h: No such file or directory
| #include 
configure:20051: checking sqlite3.h presence
conftest.cpp:128:21: error: sqlite3.h: No such file or directory
| #include 
configure:20119: checking for sqlite3.h
configure:20150: checking /usr/local/include/sqlite3.h usability
conftest.cpp:161:40: error: /usr/local/include/sqlite3.h: No such file or directory
| #include 
configure:20191: checking /usr/local/include/sqlite3.h presence
conftest.cpp:128:40: error: /usr/local/include/sqlite3.h: No such file or directory
| #include 
configure:20259: checking for /usr/local/include/sqlite3.h
configure:21294: error: Support of at least one of mysql or sqlite3 must be configured
ac_cv_header__usr_local_include_sqlite3_h=no

Immer wieder stößt man auf die Meldung, dass die Datei sqlite3.h in den angegebenen Verzeichnissen nicht gefunden werden konnte. Dateien mit der Endung *.h verweisen immer auf Header-Dateien für die Programmiersprache C/C++. Daraufhin wird überprüft, ob diese Datei nicht evtl. in einem anderen Verzeichnis existiert, welches von dem configure-Script nicht berücksichtigt wird:

whereis sqlite3.h

/usr/bin/sqlite3 /usr/include/sqlite3.h /usr/share/man/man1/sqlite3.1.gz

Offensichtlich existiert diese Datei sqlite3.h doch, aber wie vermutet befindet sie sich nicht im Suchpfad des Sripts. Nun wird das Script nochmal aufgerufen, allerdings mit der Option --help. Darin ist in einem Abschnitt beschrieben, dass man den Pfad für genau diese Header-Dateien mit dem Präfix --with-sqlite3-h=DIR als Option übergeben kann. Dies wird nun mit dem zuvor ermittelten Pfad vollzogen:

./configure --with-sqlite3-h=/usr/include/

...und leider bricht das Script wieder ab...

checking expat.h usability... no
checking expat.h presence... no
checking for expat.h... no
checking /usr/local/include/expat.h usability... no
checking /usr/local/include/expat.h presence... no
checking for /usr/local/include/expat.h... no
configure: error: unable to configure expat support

Diesmal scheint die Datei expat.h den Fehler zu verursachen. Zur Fehlerbehebung wird erstmal nach dem gleichen Schema vorgegangen, wie bei dem Problem mit der Datei sqlite3.h. Allerdings stellt sich diesmal heraus, dass die Datei expat.h wirklich nicht auf dem System existiert. Nun sollte man versuchen die Datei über den jeweiligen Paketmanager (apt, yum, etc.) ausfindig zu machen und nach zu installieren.

Anmerkung: Die Suche mit dem Paketmanager kann sich auch teilweise als recht mühsam erweisen, da er oft viele Ergebnisse liefert, die nicht immer eindeutig zuordenbar sind. Dann hilt meist nur eine Recherche im Internet zu diesem Problem. Sinnvoll ist damit auf der jeweiligen Projektseite zu beginnen.

Hier war eine Nachinstallation des Pakets libwww-dev von Erfolg gekrönt, welches die vermisste Datei wieder im Ordner /usr/include/ hinterlegt hat. Mit Hilfe der Option --help wurde noch das Präfix für die Option herausgefunden und ein erneuter Versuch wird gestartet:

./configure --with-sqlite3-h=/usr/include/ --with-expat-h=/usr/include/

...der diesmal erfolgreich durchläuft...

...
configure: creating ./config.status
config.status: creating Makefile
config.status: creating build/Makefile
config.status: creating doc/Makefile
config.status: creating scripts/Makefile
config.status: creating scripts/js/Makefile
config.status: creating tombupnp/Makefile
config.status: creating tombupnp/build/Makefile
config.status: creating web/Makefile
config.status: creating config/Makefile
config.status: creating artwork/Makefile
config.status: creating mediatomb.spec
config.status: creating autoconfig.h
config.status: creating tombupnp/upnp/inc/upnpconfig.h
config.status: tombupnp/upnp/inc/upnpconfig.h is unchanged
config.status: executing depfiles commands

CONFIGURATION SUMMARY ----

sqlite3               : yes
mysql                 : missing
libjs                 : missing
libmagic              : missing
inotify               : yes
libexif               : missing
expat                 : yes
id3lib                : missing
taglib                : missing
ffmpeg                : missing
external transcoding  : yes
libextractor          : disabled

In der Zusammenfassung wird die Unterstützung verschiedener Bibliotheken angegeben, bzw. wo diese nicht gewährleistet wird. Das hat sicherlich Auswirkungen auf den vollen Funktionsumfang des Medienserver Mediatomb, nicht jedoch auf seine grundsätzliche Funktion. Davor wird die Erstellung verschiedener Steuerdateien beschrieben, welches zum großen Teil Makefiles sind. Diese Makefiles, sowie die paar Header-Dateien, werden beim anschließenden Kompilieren verwendet, damit die ausführbare Version des Mediaservers an die lokalen Gegebenheiten des Systems angepasst ist.

Sollte man sich später dafür entscheiden, dass die eine oder andere Bibliothek doch verwendet werden soll, kann man durch das Kommando make distclean alle Steuer- und Konfigurationsdateien wieder entfernen, quasi den Urzustand des Quelltextes wieder herstellen, die gewünschten Bibliotheken nachinstallieren und das configure-Script mit entsprechenden Präfixen von neuem ausführen.

Nun kann der Übersetzungsvorgang gestartet werden, welcher seine Aktivität mit einer für Laien kaum zu verstehenden Bildschirmausgabe bestätigt:

make

Ein Kompilierungsvorgang kann, je nach Größe und Komplexität der Software, sowie der Performance des Systems viele Minuten bis Stunden andauern. Dieser Kompilierungsvorgang für Mediatomb sollte mit einer ~2GHz CPU in etwa 5 Minuten abgeschlossen sein.

Leider erweist sich die Kompilierung bei einem Fehler als nicht so auskunftsfreudig wie der Konfigurierungsvorgang. Erscheint auf dem Bildschrim in den letzten Zeilen das Schlüsselwort Fehler oder Error, dann ist ein Fehler anzunehmen. Sehr oft wird dabei auf das Fehlen von Biblotheken hingewiesen, was einen ersten Anhaltspunkt zur Fehlerbehebung darstellt. Dies kann vorkommen, wenn der Programmierer der neuen Software im configure-Script vergessen hat diverse Abhängigkeiten, bzw. deren Existenz auf dem lokalen System zu überprüfen.

Dann muss mit dem Kommando make clean (? make distclean) das Archiv von den bereits kompilierten Dateien bereinigt werden. Anschließend muss man fehlenden Bibliotheken ausfindig machen und mit dem Paketmanager nachinstallieren. Schließlich wird der Kompilierungsvorgang mit dem Befehl make erneut ausgeführt.

Der letzte Abschnitt befasst sich mit den Installations und Deinstallationsvorgang. Für den Installationsvorgang, muss man als erstes zum Benutzer root werden, da der Standardinstallationspfad /usr/bin/ (in ordentlichen Archiven der Dateien README oder INSTALL zu entnehmen) das Beschreiben durch einen normalen Benutzer nicht gestattet. Dieser Schritt wäre nicht nötig, wenn bei der Ausführung des configure-Scripts durch ein Präfix ein anderer Installationspfad angegeben worden wäre, wie z.B. ein Ordner im Heimatverzeichnis.

Viel mehr als Probleme mit Schreibrechten treten bei einer Installation allerdings selten auf. Trotzdem sollte man die Installation vorher simulieren. Dazu bietet make die Option -n an:

make -n install

Wieder durchläuft am Bildschirm eine komplexe Rückmeldung. Wie für den vorherigen Schritt mit dem Befehl make gilt, dass der Vorgang korrekt durchlaufen wurde, wenn er nicht mit Schlüsselwörtern wie Fehler oder Error endet. Wenn dem so ist, kann die Installation schließlich auch live vollzogen werden:

make install

Damit wäre der Mediaserver Mediatomb betriebsbereit, kann konfiguriert und gestartet werden.

Wie bereits anfangs angesprochen ist die Deinstallation leider alles andere als komortabel. Manchmal bieten Programme die Möglichkeit der Deinstallation durch die Ausführung des Kommandos make uninstall aus dem Quellverzeichnis heraus. Generell setzt dies in jedem Fall voraus, dass das Quellverzeichnis nach der Installation nicht durch make clean oder gar make distclean bereinigt wurde, da sonst die nötigen Informationen zur Deinstallation fehlen. Trotzdem stellt diese Variante eher die Ausnahme dar.

Effinzienter ist ein kleiner Workarround, der den Zustand des Dateisystems vor und nach der Installation erfasst und aufgrund der auftretenden Differenz die weitestgehend saubere Deinstallation ermöglicht. Da nun ein System ständig Dateien löscht und schreibt, auch wenn man als Anwender nichts dazu beiträgt, sollte man sich erstmal Gedanken darüber machen, welche Bereiche des Dateisystems von geringerer Bedeutung für die Erfassung sind.

Dazu zählet in jedem Fall das Verzeichnis /proc/, da eine Installation in diesem zum einen so gut wie ausgeschlossen ist und zum anderen in ihm immer rege Schreib- und Lesezugriffe stattfinden. Sicher gibt es noch weitere Verzeichnisse, die nach logischem Ausschlussverfahren als eher unwahrscheinliche Installationspfade in Betracht kommen, aber der angesprochene soll für diesen Zweck genügen.

Mit den gewonnenen Erkentnissen wird vor der Installation (make install) der Zustand erfasst und im Heimatverzeichnis abgespeichert:

find / -wholename '/proc' -prune -o -print > mediatomb.before

...nach der Installation (make install) erneut...

find / -wholename '/proc' -prune -o -print > mediatomb.after

...und anschliesend wird die zwangsläufig aufgetretene Differenz exportiert...

diff mediatomb.before mediatomb.after > mediatomb.uninstall

Betrachtet man sich nun die Datei mediatomb.uninstall, dann sollte der Inhalt zum größten Teil die neu installierten Dateien und deren Pfade beinhalten. Damit ist dann eine manuelle Löschung kein großes Problem mehr.

Weitere Informationen:

• Alternativ zur Erfassung des Zustands des Dateisystems bieten fast alle Distributionen die Möglichkeit aus Quelltext Pakete für die jeweiligen Paketmanager zu erstellen. Damit wird die installierte Software vom Paketmanager erfasst und kann über diesen auch komfortabel und sauber deinstalliert werden. Näheres dazu ist den Beschreibungen der jeweiligen Paketmanager zu entnehmen.