[ zurück ] [ Inhalt ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ weiter ]

Anleitung für zukünftige Debian-Maintainer
Kapitel 4 - Quellcode modifizieren


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 `Makefile.am'-Dateien erfordern einige Kenntnisse über die Funktionsweise von automake; mehr darüber finden Sie in der Hilfe `info 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 Aufruf `./configure` die entsprechenden Werte eingesetzt.

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.


4.1 Installation in ein Unterverzeichnis

Die meisten Programme installieren sich in die vorhandene Verzeichnistruktur, 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 intergriert. 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 debian/ Verzeichnisses 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 Paketes 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, warum nicht in irgendeinen anderen? Weil Debian-Pakete niemals Dateien unter /usr/local ablegt -- 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 Man-Pages 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 wir 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 *.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). 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 Installations-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 wir 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 debian/-Verzeichnis schicken müssen.

(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.)


4.2 Unterschiedliche Programmbibliotheken

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 unser libncurses Paket einen `libcurses.so' Symlink mitbringt, aber er konnte sich kein besseres ausdenken. Vorschläge sind sehr erwünscht :-)


[ zurück ] [ Inhalt ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ weiter ]

Anleitung für zukünftige Debian-Maintainer

Version 1.2, 06. April 2002.

Josip Rodin joy-mg@debian.org
Übersetzer: Erik Schanze mail@erikschanze.de
Übersetzer: Eduard Bloch blade@debian.org