Normallerweise installieren sich die Programme in Verzeichnissen unterhalb von
/usr/local. Da bei Debian-Paketen dieses Verzeichniss nicht verwendet werden
darf und ausschliesslich zur Verfügung des lokalen Administrators (oder der
User) steht, müssen Sie einen Blick auf den Erstellungsprozess werfen,
normallerweise beginnend mit dem Makefile. Das ist der Skript, mit dem
make(1)
die Arbeit automatisiert. Weitere Details über Makefiles
in Die `rules'-Datei, Abschnitt 5.4.
Beachten Sie, daß wenn ihr Programm GNU automake(1)
und/oder
autoconf(1)
verwendet, werden Sie die Änderungen in der Datei
Makefile.am bzw. Makefile.in machen müssen, weil jeder Aufruf von automake die
Datei Makefile.in mit Informationen aus Makefile.am neu erzeugt (und die
vorhandene Maikefile.in-Datei überschreibt!), genau wie jeder Aufruf von
./configure mit den Daten aus Makefile.in die fertige Makefile-Datei erzeugt.
Änderungen in Makefile.am erfordern einige Kenntnisse über die Funktionsweise
von automake; mehr darüber finden Sie in der "info"-Hilfe von
automake. Bearbeiten von Makefile.in-Dateien geht dagegen fast genauso einfach
wie das Bearbeiten von Makefiles, man muss lediglich bei der Verwendung der
Variablen aufpassen, d.h. Strings, die mit `@' umgeben sind, z.B. @CFLAGS@
oder @LN_S@; in diese werden beim ./configure-Aufruf die entsprechenden Werte
eingesetzt.
Wir können an dieser Stelle nicht auf alle Feinheiten eingehen, denn es würde den Ramen dieser Anleitung sprengen, aber an dieser Stelle tretten auch die wenigsten Probleme auf.
Die meisten Programme installieren sich in die vorhandene Verzeichnisstruktur, so dass die ausführbaren Binärdateien irgendwo in ihrem $PATH landen und die Dokumentation an einem der üblichen Positionen. Sie müssen sicherstellen, dass dies korrekt funktioniert, anderseits muss sich das Programm auch in ein alternatives Verzeichniss installieren lassen, das in unserem Fall unterhalb des debian/-Verzeichnisses erstellt wird (normallerweise debian/tmp/), aus dem die Maintainer-Tools dann das Paket bauen werden. Alles, was dieses Unterverzeichniss enthält, wird später auf das System des Benutzers installiert, mit dem einzigen Unterschied, dass dpkg den Inhalt im Stamm-Verzeichniss auspackt.
Grundsätzlich müssen sie das Programm in debian/tmp installiert, dabei soll das Programm aber auch noch dann korrekt funktionieren, wenn es im Stamm-Verzeichniss installiert ist. Mit Programmen, die GNU autoconf benutzen wird es ein leichtes Spiel sein, weil dh_make schon die richtigen Kommandos auswählt, also können Sie diesen Abschnitt vermuttich überspringen. Bei anderen Programmen müssen Sie die entsprechenden Makefiles untersuchen und ggf. anpassen. (A.d.Ü.: Bei einigen Programmen kommt man auch um das Anpassen des Quellcodes nicht herum, wenn z.B. die Pfade zu best. Konfigurationsdateien fest einkompiliert werden).
Hier ist der relevante Abschnitt des Makefiles von gentoo:
# Where to put binary on 'make install'? BIN = /usr/local/bin # Where to put icons on 'make install'? Note: if you change this, # gentoo will not find the icons as it starts up. You're going to # have to alter gentoo's icon path (in the config window, "Paths" # tab) to get it work. ICONS = /usr/local/lib/gentoo/
Bevor dieser kommt sollten Sie zwei neue Zeilen einsetzen:
# Edited for Debian GNU/Linux. DESTDIR =
Dies wird beim build-Prozess benötigt (Erklörungen kommen später in Die `rules'-Datei, Abschnitt 5.4).
Dann legt das Makefile die Position der endgültigen Programmdatei fest, dies ändern wir zu:
# Where to put binary on 'make install'? BIN = $(DESTDIR)/usr/X11R6/bin
Sie fragen sich vielleicht, warum in dieses Verzeichniss, warum nicht in irgendeinen anderen? Weil Debian klar definierte Regeln hat, die beschreiben, wohin die Programm zu installieren sind. Diese sind in dem Filesystem Hierarchy Standard näher spezifiziert (siehe /usr/share/doc/debian-policy/fhs/). Demnach soll die Binärdatei (für X11) in /usr/X11R6/bin und nicht in /usr/local/bin installiert sein, genau wie die Man-Seite in /usr/share/man/man1 statt in /usr/local/man/man1.
Danach haben wir eine etwas kompliziertere Situation. Wenn man die nächste Zeile entsprechend veröndert, also zu:
ICONS = $(DESTDIR)/usr/share/gentoo/
(das der Policy entspricht), werden Sie wahrscheinlich die C-Quelltexte direkt bearbeiten müssen. (A.d.Ü.: Warum? Ganz einfach, weil dieser Pfad beim Kompilieren nirgendwo verwendet wird, müssen wir davon ausgehen, dass der Autor die Pfadangaben direkt einkodiert hat). Aber wie und wo soll man suchen? Man kann z.B. mit
grep -n usr/local/lib *.[ch]
jedes Verzeichniss durch'grep'en, das .c- und .h-Dateien enthält. Grep wird die Stellen aufzeigen, an den der Pfadname verwendet wurde. (A.d.Ü.:Meine Idee wäre eher:
find -regex ".*\.h$\|.*\.c$"|xargs grep -n usr/local/lib | less
oder ähnliches). Nunmüssen Sie die entsprechenden Dateien bearbeiten und usr/local/lib mit den neuen Pfad ersetzen - und dabei aufpassen, dass Sie den restlichen Code nicht versauen. Keine Angst, für diese simple Aufgabe man muss nicht gleich C programmieren können ;)
Wenn alles erledigt ist, sollten Sie das Install-Target im Makefile lokalisieren (suchen Sie nach der Zeile die mit `install:' beginnt) und die Verweise auf die Verzeichnisse gegen die Variablen austauschen, die wir am Anfang definiert haben. Früher hat das Install-Target so ausgesehen:
# ----------------------------------------- Installation # You're going to have to be root to do this! install: gentoo install ./gentoo $(BIN) install icons $(ICONS) install gentoorc-example $(HOME)/.gentoorc
Nach unseren Änderungen sieht es so aus:
# ----------------------------------------- Installation # You're going to have to be root to do this! install: gentoo-target install -d $(BIN) $(ICONS) $(DESTDIR)/etc install ./gentoo $(BIN) install -m644 icons/* $(ICONS) install -m644 gentoorc-example $(DESTDIR)/etc/gentoorc install -d $(DESTDIR)/usr/share/doc/gentoo/html cp -a docs/* $(DESTDIR)/usr/share/doc/gentoo/html
Einem aufmerksamem Leser wird auffallen, dass ich gentoo zu gentoo-target geänder habe. Das nennt man auch Bugfix ;-)
Wo sie auch immer Änderungen machen, die nicht aussliesslich auf Debian bezogen sind, sollten Sie diese dem Upstream-Maintainer zukommen lassen, damit er diese in zukünftigen Programm-Versionen verwenden kann. Sie brauchen dem Upstream nicht das ganze debian/-Verzeichniss zu schicken, sondern nur die einzelnen Patches. Und versuchen Sie, dem Upstream entgegen zu kommen, in dem Sie keine Debian- oder Linux- (oder eben Unix-)spezifische Patches senden.
(A.d.Ü.: Speziell hier könnte man dem Upstream mit wenigen C-Kenntnissen helfen, in dem man die Pfade variabel macht. D.h. man verändert im Makefile die gcc-Parameter so, dass die Variable ICONS an den C-Präprozessor übergeben wird. In dem Programm verwendet man dann ICONS statt den festgelegten Pfaden.)
Das ist ein alltägliches Problem: Bibliotheken sind von Plattform zu Plattform verschieden. Z.b. kann ein Makefile ein Verweis auf eine Bibliothek enthalten, die es für Debian oder vieleicht überhaupt nicht für Linux gibt. In diesem Fall müssen wir ihn so verändern, dass eine Bibliothek verwendet wird, die es in Debian gibt und den selben Zweck erfüllt. Am besten, man kommentiert die Zeilen nur aus, weil andere vielleicht auf anderen Plattformen kompilieren und auf die gleiche Schwierigkeiten stossen.
Wenn also im Makefile (bzw. in Makefile.in) eine Zeile wie die Folgende vorkommt, und ihr Programm sich nicht kompiliert lässt:
LIBS = -lcurses -lsomething -lsomethingelse
Ändern Sie sie zum Folgenden und es könnte funktionieren:
LIBS = -lncurses -lsomething -lsomethingelse #LIBS = -lcurses -lsomething -lsomethingelse
Anleitung für zukünftige Debian-Maintainer
Version 1.0.2, 10. Juni 2001.joy-mg@debian.org
edi@ka.linux.de