Es gibt nun ein neues Unterverzeichnis 'debian' im Hauptverzeichnis des Quellcode-Pakets, in dem bereits einige Dateien liegen. Wir werden diese ändern, um die Eigenschaften des Pakets anzupassen. Die wichtigsten Dateien sind `control', `changelog', `copyright' und 'rules', die für die Erstellung jedes Pakets benötigt werden.
Diese Datei enthält verschiedene Werte, die dpkg
,
dselect
und andere Paketverwaltungs-Tools für die Paketverwaltung
benötigen.
Das ist die Datei `control', die dh_make
für uns erstellt hat:
1 Source: gentoo 2 Section: unknown 3 Priority: optional 4 Maintainer: Josip Rodin <joy-mg@debian.org> 5 Build-Depends: debhelper (>> 3.0.0) 6 Standards-Version: 3.5.2 7 8 Package: gentoo 9 Architecture: any 10 Depends: ${shlibs:Depends} 11 Description: <insert up to 60 chars description> 12 <insert long description, indented with spaces>
(Zeilennummerierung habe ich für dieses Beispiel hinzugefügt.)
Zeilen 1-6 sind Steuer-Informationen für das Quellcode-Paket.
Zeile 1 ist die Bezeichnung des Quellcode-Pakets.
Zeile 2 bestimmt die Sektion der Distribution, in die das Quellcode-Paket gehört.
Sie haben bestimmt schon gemerkt, dass Debian in Sektionen aufgeteilt ist: main (die freie Software), non-free (nicht wirklich freie Software) und contrib (freie Software, die von non-free-Sachen abhängt). Unterhalb dieser Sektionen existieren logische Untersektionen, die eine minimale Beschreibung des Pakets geben. D.h. die Sektion `admin' enthält Programme für Administration, `base' die grundlegenden Pakete, `devel' die Pakete für die Programmierer, `doc' die Dokumentation, `libs' die Programmbibliotheken, `mail' die E-Mail-Leseprogramme und -Dienste, `net' die Netzwerk-Anwendungen und Dienste, die `x11'-Sektion die X11-Programme, die nirgendwo anders unterkommen, usw.
Verändern Sie Sektion also zu x11. (Der Präfix "main/" wird angenommen, wenn Sie nichts angeben, also lassen Sie ihn weg.)
Zeile 3 beschreibt, wie wichtig es für den durchschnittlichen Benutzer wäre, das Paket zu installieren. Lesen Sie das "Policy-Manual" als Anleitung, was Sie in das Feld schreiben. Die Priorität "optional" passt eigentlich bei allen neuen Paketen.
Sektion und Priorität werden zurzeit nur von Programmen wie
dselect
benutzt, um Pakete zu sortieren und Standardparameter
auszuwählen. Wenn Sie das Paket zu Debian hochladen, können (und werden es
wahrscheinlich auch) die FTP-Maintainer diesen Wert überschreiben. Sie
erhalten dann eine Nachricht darüber per E-Mail.
Da es sich um ein normales Paket handelt und nichts anderes stört, lassen Sie es bei optional.
Zeile 4 ist der Name und die E-Mail-Adresse des Maintainers. Beachten Sie, dass dieses Feld einen gültigen "To:"-Header Eintrag für eine E-Mail enthält, weil nach einem Hochladen zu Debian das Bug Tracking System diesen Eintrag nutzt, um die Bug-E-Mails an Sie zu zustellen. Benutzen Sie keine Kommas, UND-Zeichen und Klammern.
Zeile 5 enthält eine Liste der Pakete, die zum Bauen des Pakets benötigt
werden. Einige Pakete wie gcc
und make
brauchen
nicht aufgeführt werden, siehe build-essential
Paket für Details.
Falls ein unüblicher Compiler oder andere Tools zum Bauen des Pakets benötigt
werden, dann sollten Sie diese Pakete zu der Zeile `Build-Depends' hinzufügen.
Mehrere Einträge werden durch Komma getrennt; mehr über die Syntax dieses
Feldes finden Sie in den Erläuterungen der `binary dependencies'.
An dieser Stelle können weitere Felder wie `Build-Depends-Indep', `Build-Conflicts' u.a. auftreten. Diese werden von der automatischen Paket-Erstellungs-Software in Debian genutzt, um Binär-Pakete für andere Plattformen zu bauen. Lesen Sie im Policy-Manual über Abhängigkeiten beim Paketbauen (build-dependencies) und in der Entwickler-Referenz über andere Plattformen bzw. wie man Software dahin portiert.
Mit diesem Beispiel können Sie herausfinden, welche anderen Pakete Ihr Paket zum Bauen braucht:
strace -f -o /tmp/log ./configure # or make instead of ./configure, if the package doesn't use autoconf for x in `dpkg -S $(grep open /tmp/log|\ perl -pe 's!.* open\(\"([^\"]*).*!$1!' |\ grep "^/"| sort | uniq|\ grep -v "^\(/tmp\|/dev\|/proc\)" ) 2>/dev/null|\ cut -f1 -d":"| sort | uniq`; \ do \ echo -n "$x (>=" `dpkg -s $x|grep ^Version|cut -f2 -d":"` "), "; \ done
Um die genauen Build-Abhängigkeiten für /usr/bin/foo
herauszufinden, führen Sie
objdump -p /usr/bin/foo | grep NEEDED
und für jede aufgelistete Bibliothek, z.B. libfoo.so.6
dpkg -S libfoo.so.6
aus. Dann nehmen Sie die Entwickler-Versionen (*-dev) jedes Pakets als einen
`Build-deps'-Eintrag. Wenn Sie dafür ldd
benutzen, werden auch
indirekt abhängende Bibliotheken aufgelistet und überflüssige
Build-Abhängigkeiten geliefert.
Gentoo benötigt noch xlibs-dev
, libgtk1.2-dev
und
libglib1.2-dev
um gebaut werden zu können, deshalb hängen Sie
diese an "debhelper" an.
Zeile 6 enthält die Version des Debian-Policy-Standards, dem dieses Paket entspricht, also die Version, die Sie gelesen haben, während Sie das Paket erstellten.
Zeile 8 enthält die Bezeichnung des Binär-Pakets. Üblicherweise ist sie gleich dem Namen des Quell-Pakets, aber das muss nicht immer so sein.
Zeile 9 beschreibt die CPU-Architektur für die das Binär-Paket kompiliert wird.
Wir können das bei "any" belassen, weil es dann von
dpkg-gencontrol(1)
mit dem richtigen Inhalt ersetzt wird, der für
den Rechner gilt, auf dem das Paket gebaut wird.
Wenn ihr Paket unabhängig von der Architektur funktioniert (z.B. ein Shell- oder Perl-Skript, oder Dokumentation), ändern Sie dies zu "all", und lesen Sie später unter Die Datei `rules', Abschnitt 5.4 über die Benutzung der Rule `binary-indep' statt `binary-arch'.
Zeile 10 zeigt eine der mächtigsten Eigenschaften des Paketsystems von Debian. Über spezielle Attribute kann das Verhalten des Paketmanagers in Bezug auf andere Pakete verändert werden. Neben Depends: (Abhängigkeit) gibt es noch weitere Attribute: Recommends: (Empfehlung), Suggests: (Vorschlag), Pre-Depends: (Voraussetzung), Conflicts: (Konflikt), Provides: (Enthält) und Replaces: (Ersetzt).
Die verschiedenen Paketverwaltungs-Programme verhalten sich sehr ähnlich bei
der Behandlung dieser Beziehungen (Abweichungen werden weiter unten erklärt).
(siehe dpkg(8)
, dselect(8)
, apt(8)
,
aptitude(1)
, usw.)
Und das bedeuten die Abhängigkeiten:
Das Paket wird erst installiert, wenn die hier aufgelisteten Pakete ebenfalls installiert sind. Benutzen Sie dies, wenn ihr Programm ohne diese Pakete überhaupt nicht (oder nicht vernünftig) laufen kann.
Frontends wie dselect
und aptitude
fordern Sie auf,
empfohlene Pakete zusammen mit Ihrem Paket zu installieren;
dselect
besteht sogar darauf; dpkg
und
apt-get
werden dieses Feld jedoch ignorieren. Benutzen Sie dieses
Feld, wenn die Pakete nicht zwingend erforderlich sind, aber normalerweise
mitinstalliert werden.
Wenn der Benutzer ihr Programm installiert, werden alle Frontends Sie
auffordern, die vorgeschlagenen Pakete zu installieren. dpkg
und
apt-get
kümmern sich nicht darum. Benutzen Sie dies für Pakete,
die mit ihrem Programm gut zusammenarbeiten, aber eigentlich nicht benötigt
werden.
Dies "wirkt" stärker als Depends:. Das Paket wird nicht installiert, bevor die hier aufgelisteten Pakete fertig installiert und richtig konfiguriert sind. Benutzen Sie dies sehr sparsam und erst, wenn auf der debian-devel-Mailingliste darüber diskutiert wurde. Lies: Verwenden Sie es überhaupt nicht. :-)
Das Paket wird nicht installiert, bevor alle aufgelisteten Pakete deinstalliert sind. Benutzen Sie dies, wenn ihr Programm überhaupt nicht oder nicht vernünftig laufen kann, solange eines dieser Pakete installiert ist.
Für einige Paketarten mit mehreren Alternativen wurden sog. "virtual
names" eingeführt. Die vollständige Liste dieser virtuellen Pakete finden
Sie in der Datei
/usr/share/doc/debian-policy/virtual-package-names-list.txt.gz
.
Benutzen Sie dies, wenn Ihr Paket die Funktionalität eines existierenden
virtuellen Pakets bietet.
Benutzen Sie dies, wenn Ihr Paket die Dateien eines anderen Pakets überschreibt oder dieses Paket vollständig ersetzt (benutzt zusammen mit Conflicts:). Die Dateien des genannten Pakets werden mit den Dateien aus Ihrem Paket überschrieben.
All diese Felder haben eine einheitliche Syntax. Dies ist eine Liste der Paketnamen, getrennt durch Kommas. Ein Paketname kann auch aus einer Liste der alternativen Paketnamen bestehen, die durch senkrechte Striche | ("pipe"-Zeichen) getrennt werden.
Die Angabe des Pakets kann auch auf ganz bestimmte Paketversionen beschränkt werden. Diese Versionen werden in Klammern nach jedem einzelnen Paketnamen aufgeführt und werden durch spezielle Symbole festgelegt, gefolgt von einer Versionsnummer. Folgende Symbole sind erlaubt: <<, <=, =, >= und >> für niedriger, niedriger oder gleich, gleich, höher oder gleich und höher. Zum Beispiel:
Depends: foo (>= 1.2), libbar1 (= 1.3.4) Conflicts: baz Recommends: libbaz4 (>> 4.0.7) Suggests: quux Replaces: quux (<< 5), quux-foo (<= 7.6)
Das letzte Feature, das erwähnt werden sollte, ist die Variable
${shlibs:Depends}. Nachdem Ihr Paket gebaut und in das
Unterverzeichnis (A.d.Ü.: debian/tmp) installiert wurde, wird es von
dh_shlibdeps(1)
nach Binär-Dateien und Bibliotheken durchsucht, um
Abhängigkeiten zu `shared libraries' festzustellen und herauszufinden, in
welchen Paketen diese stecken, wie z.B. libc6 oder xlib6g. Die Liste wird an
dh_gencontrol(1)
weiter gegeben um sie an die richtige Stelle zu
setzen. Darum brauchen Sie sich nicht zu kümmern.
Wie schon gesagt, Sie lassen die Depends: Zeile wie sie ist und fügen darunter eine neue Zeile Suggests: file, weil gentoo für einige Funktionen dieses Programm/Paket braucht.
Zeile 11 enthält eine Kurzbeschreibung. Bei den meisten Leuten sind die Terminalzeilen 80 Zeichen breit, also sollte die Kurzbeschreibung nicht länger als 60 Zeichen sein. Sie ändern es in "fully GUI configurable X file manager using GTK+".
In die Zeile 12 kommt eine ausführliche Beschreibung des Pakets. Sie sollte aus einem kleinen Text bestehen, der mehr über das Paket verrät. Die erste Spalte der Zeilen sollte immer leer sein. Es dürfen keine leeren Zeilen vorkommen, Sie können aber welche simulieren, indem Sie einen einzelnen . (Punkt) in die Zeile einsetzen. Es darf nach der ausführlichen Beschreibung auch nicht mehr als eine Leerzeile vorkommen.
Und so sieht die angepasste Datei `control' aus:
1 Source: gentoo 2 Section: x11 3 Priority: optional 4 Maintainer: Josip Rodin <joy-mg@debian.org> 5 Build-Depends: debhelper(>> 3.0.0),xlibs-dev,libgtk1.2-dev,libglib1.2-dev 6 Standards-Version: 3.6.1 7 8 Package: gentoo 9 Architecture: any 10 Depends: ${shlibs:Depends} 11 Suggests: file 12 Description: fully GUI configurable X file manager using GTK+ 13 gentoo is a file manager for Linux written from scratch in pure C. It 14 uses the GTK+ toolkit for all of its interface needs. gentoo provides 15 100% GUI configurability; no need to edit config files by hand and re- 16 start the program. gentoo supports identifying the type of various 17 files (using extension, regular expressions, or the 'file' command), 18 and can display files of different types with different colors and icons. 19 . 20 gentoo borrows some of its look and feel from the classic Amiga file 21 manager "Directory OPUS" (written by Jonathan Potter).
(Die Zeilennummerierung habe ich für dieses Beispiel hinzugefügt.)
In dieser Datei stehen Informationen über die Herkunft des Pakets (bzw. der Quellen), über die Lizenz und das Urheberrecht (Copyright). Die Policy schreibt keine bestimmte Form vor, aber den benötigten Inhalt (siehe Abschnitt 13.6 "Copyright information").
dh_make
erstellt uns eine Standardvorlage, die etwa so aussieht:
1 This package was debianized by Josip Rodin <joy-mg@debian.org> on 2 Wed, 11 Nov 1998 21:02:14 +0100. 3 4 It was downloaded from <fill in ftp site> 5 6 Upstream Author(s): <put author(s) name and email here> 7 8 Copyright: 9 10 <Must follow here>
(Die Zeilennummerierung habe ich für dieses Beispiel hinzugefügt.)
Die wichtigsten Dinge, die Sie hier einzutragen haben, sind die Quelle, von der
Sie das Paket bezogen haben, die geltenden Copyright-Vermerke und die Lizenz.
Sie müssen die komplette Lizenz einfügen, sofern es sich nicht um eine der
gängigen freien Softwarelizenzen handelt, z.B. die GNU GPL oder LGPL, die BSD-
oder die Artistic-License; in diesem Fall reicht ein Verweis auf die
entsprechende Datei im Verzeichnis /usr/share/common-licenses/
,
das auf jedem Debian-System existieren sollte.
Gentoo's Datei `copyright' sollte also so aussehen:
1 This package was debianized by Josip Rodin <joy-mg@debian.org> on 2 Wed, 11 Nov 1998 21:02:14 +0100. 3 4 It was downloaded from: ftp://ftp.obsession.se/gentoo/ 5 6 Upstream author: Emil Brink <emil@obsession.se> 7 8 This software is copyright (c) 1998-99 by Emil Brink, Obsession 9 Development. 10 11 You are free to distribute this software under the terms of 12 the GNU General Public License. 13 On Debian systems, the complete text of the GNU General Public 14 License can be found in the file `/usr/share/common-licenses/GPL'.
(Die Zeilennummerierung habe ich für dieses Beispiel hinzugefügt.)
Dies ist eine zwingend vorgeschriebene Datei, deren Format in der Policy
Sektion 4.4 "debian/changelog" beschrieben wird. Dieses Format
benötigen dpkg
und andere Programme um Dinge wie Versionsnummer,
Revision, Distribution und die Wichtigkeit ihres Pakets zu bestimmen.
Für Sie ist die Datei ebenfalls wichtig, weil man hier die gemachten Änderungen
dokumentieren kann. Damit können Leute, die Ihr Paket herunterladen, einfacher
herausfinden, ob es Probleme mit dem Paket gibt, die sie kennen sollten. Diese
Datei wird im Binär-Paket als
/usr/share/doc/gentoo/changelog.Debian.gz
gespeichert.
dh_make
erstellt eine Standardvorlage, die etwa so aussieht:
1 gentoo (0.9.12-1) unstable; urgency=low 2 3 * Initial Release. 4 5 -- Josip Rodin <joy-mg@debian.org> Wed, 11 Nov 1998 21:02:14 +0100 6
(Die Zeilennummerierung habe ich für dieses Beispiel hinzugefügt.)
In der Zeile 1 stehen der Paketname, die Version, die Distribution und die Wichtigkeit. Der Name muss mit dem Namen des Quell-Pakets übereinstimmen, Distribution sollte vorerst `unstable' (oder sogar `experimental') sein und die Priorität nicht höher als `low'. :-)
Zeilen 3-5 sind Log-Einträge, in den Sie die in dieser Revision gemachten
Änderungen dokumentieren können. (Hierher kommt nichts über die Änderungen des
Upstream-Maintainers, für diese Zwecke gibt es eine separate Datei, die Sie
später als /usr/share/doc/gentoo/changelog.gz
speichern werden.)
Neue Zeilen werden direkt über die oberste Zeile, die mit einem Stern (`*')
beginnt, eingefügt. Sie können das mit dch(1)
, oder per Hand mit
einem Texteditor erledigen.
Schließlich kommen Sie zu einer Datei wie dieser hier:
1 gentoo (0.9.12-1) unstable; urgency=low 2 3 * Initial Release. 4 * This is my first Debian package. 5 * Adjusted the Makefile to fix $DESTDIR problems. 6 7 -- Josip Rodin <joy-mg@debian.org> Wed, 11 Nov 1998 21:02:14 +0100 8
(Die Zeilennummerierung habe ich für dieses Beispiel hinzugefügt.)
Mehr über Änderungen in der Datei `changelog' können Sie später in Weiterentwicklung des Pakets, Kapitel 10 lesen.
Nun müssen Sie einen Blick auf die eigentlichen Befehlssequenzen, sog. Rules,
werfen, mit denen dpkg-buildpackage(1)
das Paket schließlich
erstellt. Die Datei `rules' ist im Prinzip ein weiteres Makefile,
unterscheidet sich aber von denen des Upstream-Autors. Im Gegensatz zu anderen
Dateien in debian/ ist diese Datei ausführbar.
Wie jedes andere Makefile besteht die Datei `rules' aus mehreren Rules, die bestimmen, wie mit dem Quellcode verfahren wird. Jede Rule besteht wiederum aus weiteren Targets, Dateinamen oder Namen der Aktionen, die durchgeführt werden (z.B. `build:' oder `install:'). Rules, die Sie ausführen möchten, werden beim Aufruf als Programmparameter angegeben (z.B., `./debian/rules build` oder `make -f rules install`). Nach dem Targetnamen (A.d.Ü.: nach der Bezeichnung unserer Rule) können Sie Programme oder Dateinamen angeben, von der die Ausführung der Rule abhängt. Danach folgt eine beliebige Anzahl von Kommandos, eingerückt mit <tab>. Eine neue Rule beginnt mit der Deklaration eines Targets in der ersten Spalte. Leerzeilen und mit einem `#' (hash) beginnende Zeilen werden als Kommentare betrachtet und ignoriert.
Sie sind vielleicht etwas verwirrt, aber es wird alles verständlich nach der
genaueren Betrachtung der Datei `rules', die uns dh_make
erstellt
hat. Sie sollten evtl. die Info-Seiten von make
lesen, um mehr
über die Funktionsweise zu erfahren.
Wichtig zu wissen ist noch, dass dh_make
nur ein Muster der Datei
`rules' erzeugt, also einen Vorschlag, wie sie ungefähr auszusehen hat. Diese
Datei wird für einfache Pakete wahrscheinlich funktionieren, aber bei
komplizierteren sollten Sie die Datei nach Bedarf anpassen und erweitern. Sie
dürfen nur die Namen der Rules nicht ändern, weil diese in der Policy
vorgeschrieben sind und von allen Programmen (für die Paketerstellung) so
erwartet werden.
1 #!/usr/bin/make -f 2 # Sample debian/rules that uses debhelper. 3 # GNU copyright 1997 to 1999 by Joey Hess. 4 5 # Uncomment this to turn on verbose mode. 6 #export DH_VERBOSE=1 7 8 # This is the debhelper compatibility version to use. 9 export DH_COMPAT=4 10 11 CFLAGS = -g 12 ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS))) 13 CFLAGS += -O0 14 else 15 CFLAGS += -O2 16 endif 17 18 build: build-stamp 19 build-stamp: 20 dh_testdir 21 22 # Add here commands to compile the package. 23 $(MAKE) 24 #docbook-to-man debian/gentoo.sgml > gentoo.1 25 26 touch build-stamp 27 28 clean: 29 dh_testdir 30 dh_testroot 31 rm -f build-stamp 32 33 # Add here commands to clean up after the build process. 34 -$(MAKE) clean 35 36 dh_clean 37 38 install: build 39 dh_testdir 40 dh_testroot 41 dh_clean -k 42 dh_installdirs 43 44 # Add here commands to install the package into debian/gentoo. 45 $(MAKE) install DESTDIR=$(CURDIR)/debian/gentoo 46 47 # Build architecture-independent files here. 48 binary-indep: build install 49 # We have nothing to do by default. 50 51 # Build architecture-dependent files here. 52 binary-arch: build install 53 dh_testdir 54 dh_testroot 55 # dh_installdebconf 56 dh_installdocs 57 dh_installexamples 58 dh_installmenu 59 # dh_installlogrotate 60 # dh_installemacsen 61 # dh_installpam 62 # dh_installmime 63 # dh_installinit 64 dh_installcron 65 dh_installman 66 dh_installinfo 67 # dh_undocumented 68 dh_installchangelogs ChangeLog 69 dh_link 70 dh_strip 71 dh_compress 72 dh_fixperms 73 # dh_makeshlibs 74 dh_installdeb 75 # dh_perl 76 dh_shlibdeps 77 dh_gencontrol 78 dh_md5sums 79 dh_builddeb 80 81 binary: binary-indep binary-arch 82 .PHONY: build clean binary-indep binary-arch binary install
(Zeilennummerierung habe ich für dieses Beispiel hinzugefügt. In der richtigen
Datei debian/rules
sind die führenden Leerzeichen ein TAB.)
Die Funktion der ersten Zeile kennen Sie vielleicht von Perl- oder
Shell-Skripten. Sie teilt dem Betriebssystem mit, dass das Skript mit
/usr/bin/make
interpretiert wird.
Die Zeilen 6 bis 9 enthalten Variablen DH_*, deren Bedeutung durch
die Kurzbeschreibung klar werden sollte. Mehr Informationen über
DH_COMPAT finden Sie in dem Kapitel "Debhelper compatibility
levels" in der Manpage debhelper(1)
.
Die Zeilen 11 bis 16 beinhalten ein Grundgerüst für die Auswertung der Parameter in DEB_BUILD_OPTIONS, die in der Policy, Kapitel 11.1 "Binaries" beschrieben sind. Im Grunde steuern Sie hier, ob die Binär-Dateien mit Debugging-Informationen gebaut werden und ob diese während der Installation wieder entfernt werden sollen. Nochmal, es ist ein Grundgerüst, ein Hinweis, dass Sie so vorgehen können. Sie müssen herausfinden, wie das Einfügen und Entfernen von Debugging-Informationen im Upstream-Quellcode gehandhabt wird und es selbst einbauen.
Normalerweise sollten Sie die Variable CFLAGS benutzen, um
gcc
mit der Option "-g" aufzurufen. Wenn Sie das tun,
dann sollten Sie die Variable mittels CFLAGS="$(CFLAGS)"
an den Aufruf $(MAKE) in der Rule `build' anhängen (siehe
unten). Wenn Ihr Paket aber ein autoconf-Skript verwendet, können Sie die
Variable an `configure' übergeben, indem Sie die o. g. Zeichenkette dem
Aufruf `./configure` in der Rule `build' voranstellen.
Weil Sie gerade beim "stripping" sind. :-) Häufig sind Programme so
konfiguriert, dass sie ungestrippt installiert werden, oft ohne eine
Möglichkeit, das zu ändern. Zum Glück haben Sie dh_strip(1)
, das
das Flag DEB_BUILD_OPTIONS=nostrip erkennt und still endet.
Zeilen 18 bis 26 enthalten die Rule `build' (und die untergeordnete
`build-stamp'-Rule), die mit dem Makefile der Anwendung das Programm
kompiliert. Wenn Ihr Paket die "GNU configure"-Werkzeuge benutzt,
sollten Sie unbedingt
/usr/share/doc/autotools-dev/README.Debian.gz
gelesen haben. Auf
die auskommentierte Zeile der docbook-to-man Umwandlung wird später in manpage.1.ex, manpage.sgml.ex, Abschnitt
6.8 eingegangen.
Die Rule `clean' in den Zeilen 28-36 entsorgt alle unnötigen Binär- und automatisch generierten Dateien, die nach der Paketerstellung zurückbleiben. Diese Rule muss jederzeit funktionsfähig sein, auch wenn im Quellcode-Verzeichnis bereits aufgeräumt wurde, also sollten Sie evtl. die "Zwang"-Optionen benutzen (z.B. "-f" bei rm), oder die Rückgabewerte (Fehler) mit einem `-' am Anfang des Befehls ignorieren.
Der Installationsprozess, die Rule `install', beginnt in der Zeile 38. Es wird einfach die Rule `install' des programmeigenen Makefiles ausgeführt, aber in das Verzeichnis $(CURDIR)/debian/gentoo installiert - aus diesem Grund haben Sie in gentoo's Makefile auch die Variable $(DESTDIR) (als Root-Verzeichnis der Installation) eingebaut.
Die Rule `binary-indep' in der Zeile 48, ist, wie der Kommentar bereits sagt, für die Erstellung von architekturunabhängigen Paketen vorgesehen. Das ist bei Ihrem Paket nicht der Fall, also wird hier auch nichts gemacht.
Auf zur nächsten Rule - `binary-arch' in den Zeilen 52 bis 79, in der
verschiedene kleine Hilfsprogramme aus dem Paket dephelper
gestartet werden, die an unseren Dateien verschiedene Operationen durchführen,
um das Paket an die Policy anzupassen.
Wenn Ihr Paket `Architecture: all' entspricht, dann müssen Sie alle Kommandos zum Bauen des Pakets in der Rule `binary-indep' platzieren und die Rule `binary-arch' dafür leer lassen.
Die Namen der debhelper-Programme beginnen mit dh_ und der Rest erklärt bereits die Aufgabe des Tools. Alles ist praktisch selbsterklärend, hier dennoch einige zusätzlichen Erläuterungen:
dh_testdir(1)
überprüft, ob Sie im richtigen Verzeichnis sind
(d.h. im obersten Verzeichnis des Quellcode-Verzeichnisbaums).
dh_testroot(1)
überprüft, ob Sie root-Rechte besitzen, die für die
Targets `binary-arch', `binary-indep' und `clean' benötigt werden.
dh_installmanpages(1)
kopiert die Manpages an die richtige Stelle
im Zielverzeichnis, Sie müssen nur angeben, wo sie relativ zum obersten
Verzeichnis des Quellcode-Verzeichnisbaums zu finden sind.
dh_strip(1)
"strippt" (A.d.Ü.: siehe auch
strip(1)
) die Debugging-Header aus Bibliotheken und ausführbaren
Dateien, um die Dateigröße zu reduzieren.
dh_compress(1)
komprimiert Manpages und Doku-Dateien, die größer
als 4 kB sind mit gzip(1)
.
dh_installdeb(1)
kopiert sonstige, fürs Paket benötigte Dateien
(z.B. die Maintainer-Skripte) ins Verzeichnis `debian/gentoo/DEBIAN'.
dh_shlibdeps(1)
berechnet Abhängigkeiten von Bibliotheken und
anderen Binär-Dateien.
dh_gencontrol(1)
installiert eine angepasste Version der Datei
`control' in das Verzeichnis debian/gentoo/DEBIAN
.
dh_md5sums(1)
generiert MD5-Prüfsummen für alle Dateien im Paket.
Die vollständigen Infos über die Aufgaben und Bedienung all dieser dh_*-Skripte finden Sie in den jeweiligen Manpages. Es gibt noch weitere (möglicherweise sehr nützliche) dh_*-Skripte, die hier nicht weiter erwähnt werden. Wenn Sie die mal brauchen, lesen Sie die Debhelper-Dokumentation.
Die Sektion "binary-arch" ist eine, in der Sie wirklich alle Zeilen, in den nicht benötigte Features installiert werden, auskommentieren oder entfernen sollten. Bei Gentoo kommentieren Sie Zeilen mit folgenden Befehlen aus, weil Gentoo diese nicht braucht: examples, cron, init, man und info. In der Zeile 68 werden Sie `ChangeLog' durch `FIXES' ersetzen, weil das der Name der Changelog-Datei des Upstreams ist.
Die letzten zwei Zeilen sind (genau wie andere, nicht weiter erklärte Zeilen)
mehr oder weniger benötigte Dinge, über die Sie mehr im
make
-Manual oder der Policy nachlesen können. Im Moment brauchen
Sie darüber nichts zu wissen.
Anleitung für zukünftige Debian-Maintainer
Version 1.2.3, 18. Januar 2005.joy-mg@debian.org
mail@erikschanze.de
blade@debian.org