Normalerweise installieren sich die Programme in Verzeichnissen unterhalb von
/usr/local/
. Da bei Debian-Paketen dieses Verzeichnis nicht
verwendet werden darf und ausschließlich zur Verfügung des lokalen
Administrators (oder der User) steht, müssen Sie einen Blick auf den
Erstellungsprozess werfen, normalerweise beginnend mit dem Makefile. Das ist
das Skript, mit dem make(1)
die Arbeit automatisiert. Weitere
Details über Makefiles in Die Datei `rules',
Abschnitt 5.4.
Beachten Sie, dass 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 Datei `Makefile.in' überschreibt!), genau wie jeder Aufruf von
./configure mit den Daten aus `Makefile.in' das fertige Makefile erzeugt.
Änderungen in Dateien `Makefile.am' erfordern einige Kenntnisse über die
Funktionsweise von automake
; mehr darüber finden Sie in der Hilfe
`info automake`. Das Bearbeiten von Dateien `Makefile.in' ist 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 Aufruf
`./configure` die entsprechenden Werte eingesetzt. Bitte lesen Sie
/usr/share/doc/autotools-dev/README.Debian.gz
, bevor Sie
weitermachen.
Wir können an dieser Stelle nicht auf alle Feinheiten eingehen, denn es würde den Rahmen dieser Anleitung sprengen, aber an dieser Stelle treten auch die wenigsten Probleme auf.
Die meisten Programme installieren sich in die vorhandene Verzeichnisstruktur, so dass die ausführbaren Binär-Dateien irgendwo in ihrem $PATH landen und die Dokumentation an einer der üblichen Positionen. Wenn Sie so vorgehen, wird das Programm aber in Ihr System integriert. Die Paket-Erstellungs-Tools werden es dadurch schwer haben, herauszufinden, welche Dateien zu Ihrem Paket gehören und welche nicht.
Deshalb sollten Sie anders verfahren: Installieren Sie das Programm in ein angelegtes Unterverzeichnis von dem aus die Paket-Erstellungs-Tools ein funktionierendes .deb-Paket erzeugen werden. Alles, was dieses Unterverzeichnis enthält, wird später auf das System der Benutzer installiert, mit dem einzigen Unterschied, dass dpkg den Inhalt im Stamm-Verzeichnis auspackt.
Dieses Unterverzeichnis wird üblicherweise unterhalb des Verzeichnisses
debian/
im ausgepackten Quellverzeichnis angelegt. Man nennt es
debian/tmp
oder debian/paketname
.
Denken Sie daran, auch wenn Sie das Programm in debian/paketname
installieren, muss es korrekt funktionieren wenn es in das root-Dateisystem
übernommen wird, z.B. wenn es aus einem .deb-Paket installiert wird. Sie
müssen dafür sorgen, dass beim Erstellen des Pakets keine fest
einprogrammierten Werte in den Dateien auftreten wie
/home/me/deb/gentoo-0.9.12/usr/share/gentoo
.
Mit Programmen, die GNU autoconf
benutzen wird es ein leichtes
Spiel sein. Die meisten dieser Programme nutzen Makefiles, die es
standardmäßig erlauben, das Programm in irgendein Unterverzeichnis zu
installieren, ohne zu vergessen, dass /usr der vorschriftsmäßige Präfix ist.
dh_make
wählt die richtigen Kommandos, wenn es feststellt, dass
Ihr Programm autoconf
benutzt, also können Sie diesen Abschnitt
vermutlich ü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'? ICONS = /usr/local/lib/gentoo/
Sie sehen, die Dateien sollen unter /usr/local
installiert werden,
dies ändern Sie zu:
# Where to put binary on 'make install'? BIN = $(DESTDIR)/usr/bin # Where to put icons on 'make install'? ICONS = $(DESTDIR)/usr/share/gentoo
Sie fragen sich vielleicht, warum in dieses Verzeichnis und nicht in irgendein
anderes? Weil Debian-Pakete niemals Dateien unter /usr/local
ablegen -- dieses Verzeichnis ist für den Systemadministrator reserviert.
Debian nutzt statt dessen /usr
.
Eine genauere Beschreibung der Installationsverzeichnisse für Binär-Dateien,
Icons und Dokumentationen finden Sie im Filesystem Hierarchy Standard (siehe
/usr/share/doc/debian-policy/fhs/
). Schauen Sie es sich an und
lesen Sie die Passagen, die Ihr Paket betreffen könnten.
Sie sollten also die Binär-Dateien in /usr/bin/
anstatt
/usr/local/bin/
, die Manpages in /usr/share/man/man1/
anstatt /usr/local/man/man1/
installieren. Beachten Sie, dass
gentoo's Makefile nicht die Installation einer Manpage vorsieht, doch die
Debian Policy verlangt, dass jedes Programm eine hat. Sie schreiben später
eine und installieren sie nach /usr/share/man/man1/
.
Manche Programmierer nutzen leider das Makefile nicht, um die Pfade o.ä. variabel zu gestalten. Das bedeutet, dass Sie wahrscheinlich die C-Quelltexte direkt bearbeiten müssen. (A.d.Ü.: Warum? Ganz einfach, weil dieser Pfad beim Kompilieren nirgendwo verwendet wird, müssen Sie davon ausgehen, dass der Autor die Pfadangaben direkt einkodiert hat). Aber wie und wo soll man suchen? Man kann z.B. mit
grep -rn usr/local/lib *.[ch]
das Quellen-Verzeichnis rekursiv durch'grep'en, das Dateien *.c und *.h 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). Nun müssen Sie die entsprechenden Dateien bearbeiten und "/usr/local/" durch "/usr/" ersetzen und dabei aufpassen, dass Sie den restlichen Code nicht beschädigen. :-)
Wenn alles erledigt ist, sollten Sie das Install-Target im Makefile lokalisieren (Es sollte normalerweise helfen, wenn Sie nach der Zeile, die mit `install:' beginnt, suchen.) und die Verweise auf die Verzeichnisse gegen die Variablen austauschen, die Sie am Anfang definiert haben. Vorher hat das Install-Target so ausgesehen:
install: gentoo install ./gentoo $(BIN) install icons/* $(ICONS) install gentoorc-example $(HOME)/.gentoorc
Nach unseren Änderungen sieht es so aus:
install: gentoo-target install -d $(BIN) $(ICONS) $(DESTDIR)/etc install ./gentoo $(BIN) install -m644 icons/* $(ICONS) install -m644 gentoorc-example $(DESTDIR)/etc/gentoorc
Sie haben sicherlich bemerkt, dass es jetzt ein Kommando install
-d vor allen anderen in der Rule gibt. Das Original-Programm hatte das
nicht, weil normalerweise die ursprünglichen Verzeichnisse
/usr/local/bin/
u.a. schon auf dem System existieren, wenn `make
install` aufgerufen wird. Weil Sie aber in Ihr eigenes, leeres (oder sogar
nicht vorhandenes) Verzeichnis installieren, müssen Sie jedes Verzeichnis
vorher anlegen.
Sie können noch Weiteres am Ende der Rule anfügen, wie z.B. die Installation einer Dokumentation, die der Upstream-Autor manchmal weglässt.
install -d $(DESTDIR)/usr/share/doc/gentoo/html cp -a docs/* $(DESTDIR)/usr/share/doc/gentoo/html
Einem aufmerksamen Leser wird auffallen, dass gentoo zu gentoo-target geändert wurde. Das nennt man auch unverlangten Bugfix. ;-)
Wo auch immer Sie Änderungen machen, die nicht ausschließlich auf Debian bezogen sind, sollten Sie diese dem Upstream-Maintainer zukommen lassen, damit er diese in zukünftigen Programm-Versionen verwenden kann und sie für alle Anderen nützlich sein können. Und versuchen Sie, dem Upstream entgegen zu kommen, indem Sie keine Debian- oder Linux- (oder eben Unix-) spezifischen Patches senden, sondern gestalten Sie diese portabel. Dadurch kann er Ihre Bugfixes besser übernehmen.
Beachten Sie außerdem, dass Sie dem Upstream nicht das ganze Verzeichnis
debian/
schicken müssen.
(A.d.Ü.: Speziell hier könnte man dem Upstream mit wenigen C-Kenntnissen helfen, indem 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 einen Verweis auf eine Bibliothek enthalten, die es für Debian nicht gibt. In diesem Fall müssen Sie das Makefile so verändern, dass eine Bibliothek verwendet wird, die es in Debian gibt und den selben Zweck erfüllt.
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
Der Autor ist sich bewusst, dass dies nicht das beste Beispiel ist, weil das
Paket libncurses
einen Symlink libcurses.so
mitbringt, aber er konnte sich kein besseres ausdenken. Vorschläge sind sehr
erwünscht :-)
Anleitung für zukünftige Debian-Maintainer
Version 1.2.3, 18. Januar 2005.joy-mg@debian.org
mail@erikschanze.de
blade@debian.org