[ zurück ] [ Inhalt ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ weiter ]
debian
Im Quellverzeichnis des Programms gibt es ein neues Unterverzeichnis, das
debian heißt. In diesem Verzeichnis sind einige Dateien, die wir
ändern müssen, um die Eigenschaften des Pakets anzupassen. Die wichtigsten
davon sind control, changelog, copyright
und rules, die für jedes Paket benötigt werden.
control
Diese Datei enthält verschiedene Werte, die dpkg,
dselect, apt-get, apt-cache,
aptitude und andere Paketverwaltungswerkzeuge verwenden, um das
Paket zu verwalten. Sie wird in den Debian-Richtlinien,
Kapitel 5 »Control files and their fields« festgelegt.
Dies ist die Datei »control«, die dh_make für uns erstellt hat:
1 Source: gentoo
2 Section: unknown
3 Priority: extra
4 Maintainer: Josip Rodin <joy-mg@debian.org>
5 Build-Depends: debhelper (>= 7.0.50~)
6 Standards-Version: 3.8.4
7 Homepage: <insert the upstream URL, if relevant>
8
9 Package: gentoo
10 Architecture: any
11 Depends: ${shlibs:Depends}, ${misc:Depends}
12 Description: <insert up to 60 chars description>
13 <insert long description, indented with spaces>
(Die Zeilennummerierung habe ich hinzugefügt.)
Die Zeilen 1-6 sind die Steuerinformationen für das Quellcode-Paket.
Zeile 1 ist der Name des Quellcode-Pakets.
Zeile 2 bestimmt die Sektion der Distribution, in die das Quellcode-Paket gehört.
Sie haben bestimmt schon gemerkt, dass das Debianarchiv in Sektionen aufgeteilt
ist: main (freie Software), non-free (nicht wirklich
freie Software) und contrib (freie Software, die von
non-free-Software abhängt). Unterhalb dieser Sektionen existieren logische
Untersektionen, die eine minimale Beschreibung der Pakete geben.
Dementsprechend enthält die Sektion admin Programme für
dieAdministration, base die grundlegenden Pakete,
devel die Pakete für die Programmierer, doc die
Dokumentation, libs die Programmbibliotheken, mail
die E-Mail-Leseprogramme und -Daemons, net die
Netzwerk-Anwendungen und Daemons, x11 die X11-Programme, die
nirgendwo anders unterkommen und viele mehr. Siehe die Debian-Richtlinien,
Kapitel 2.4 »Sections« und die Liste der Sektionen in
»Sid« für eine Orientierung.
Verändern Sie die Sektion also zu x11 (Das Präfix main/ wird impliziert, also können wir es weglassen).
Zeile 3 beschreibt, wie wichtig es ist, dass der Benutzer das Paket
installiert. Lesen Sie die Debian-Richtlinien,
2.5 »Priorities« als Anleitung.
Die Priorität optional ist normalerweise für neue Pakete sinnvoll, die nicht mit anderen Paketen der Prioritäten required, important oder standard kollidieren.
Die Priorität extra ist normalerweise für neue Pakete sinnvoll, die mit anderen Paketen kollidieren, die eine andere Priorität als extra besitzen.
Sektion und Priorität werden von Frontends wie aptitude benutzt,
um Pakete zu sortieren und Standardparameter auszuwählen. Wenn Sie das Paket
für Debian hochladen, können die Werte dieser beiden Felder von den
Archivbetreuern überschrieben werden. Sie erhalten dann eine Nachricht
darüber per E-Mail.
Da es sich um ein Paket mit normaler Priorität handelt und nichts anderes stört, ändern wir die Priorität auf »optional«.
Zeile 4 ist der Name und die E-Mail-Adresse des Betreuers. Sie müssen sicherstellen, dass dieses Feld eine gültige »To«-Kopfzeile für eine E-Mail enthält, weil nach dem Hochladen das Fehlerverfolgungssystem diesen Eintrag nutzt, um die Fehler-E-Mails an Sie zuzustellen. Benutzen Sie keine Kommata, das Et-Zeichen (&) oder Klammern.
Zeile 5 enthält die Liste der Pakete, die zum Bauen des Pakets benötigt
werden, im Feld Build-Depends. Sie können hier ebenso das Feld
Build-Depends-Indep in einer zusätzlichen Zeile benutzen (siehe
die Debian-Richtlinien,
7.7 »Relationships between source and binary packages - Build-Depends,
Build-Depends-Indep, Build-Conflicts, Build-Conflicts-Indep«).
Einige Pakete wie gcc und make werden impliziert,
weil sie vom Paket build-essential benötigt werden. Falls Sie
andere Werkzeuge zum Bauen Ihres Pakets brauchen, müssen Sie sie zu diesen
Feldern hinzufügen. Mehrere Einträge werden durch Kommata getrennt; mehr
über die Syntax dieser Zeilen finden Sie in den Erläuterungen der binären
Abhängigkeiten.
Bei allen Paketen, die auf den Befehl dh in der Datei
debian/rules zugreifen, müssen Sie »debhelper
(>=7.0.50~)« in das Feld Build-Depends eintragen, um
die Debian-Richtlinien für das Target clean zu erfüllen.
Bei Quellpaketen, die binäre Pakete mit »Architecture: any« erstellen, werden diese vom automatischen Buildsystem (»Autobuilder«) neu gebaut. Da während dieser Autobuilder-Prozedur »debian/rules build« aufgerufen wird und nur Pakete installiert werden, die im Feld Build-Depends aufgeführt sind (siehe Autobuilder, Abschnitt 6.2), muss das Feld Build-Depends praktisch alle erforderlichen Pakete auflisten. Das Feld Build-Depends-Indep wird daher selten benutzt.
Bei Quellpaketen, die nur binäre Pakete mit »Architecture: all« erstellen, kann das Feld Build-Depends-Indep alle erforderlichen Pakete auflisten, es sei denn, diese sind bereits im Feld Build-Depends aufgeführt, um die Debian-Richtlinie für das Target clean zu erfüllen.
Wenn Sie sich nicht sicher sind, welches von beiden Sie benutzen sollten, verwenden Sie das Feld Build-Depends, um auf der sicheren Seite zu sein. [15]
Um herauszufinden, welche Pakete Ihr Paket zum Bauen benötigt, führen Sie diesen Befehl aus:
$ dpkg-depcheck -d ./configure
Um die genauen Build-Abhängigkeiten für /usr/bin/foo
manuell herauszufinden, führen Sie
$ objdump -p /usr/bin/foo | grep NEEDED
aus. Rufen Sie dann für jede aufgelistete Bibliothek, beispielsweise
libfoo.so.6, diesen Befehl auf:
$ dpkg -S libfoo.so.6
Dann nehmen Sie die Entwicklerversion (-dev) jedes Pakets als
einen Build-Depends-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 wir diese direkt hinter debhelper an.
Zeile 6 enthält die Version der Debian-Richtlinien,
dessen Standards dieses Paket entspricht, also die Version, die Sie gelesen
haben, während Sie Ihr Paket erstellten.
In Zeile 7 können Sie die URL der Homepage für das ursprüngliche Programm notieren.
Zeile 9 enthält den Namen des Binärpakets. Üblicherweise ist dies der gleiche Name wie der des Quellpakets, aber das muss nicht immer so sein.
Zeile 10 beschreibt die CPU-Architektur, für die das Binärpaket kompiliert
werden kann. 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 (beispielsweise ein
Shell- oder Perl-Skript oder Dokumentation), ändern Sie dies in
»all« und lesen Sie später unter Die Datei
rules, Abschnitt 4.4 über die Benutzung der Regel
binary-indep statt binary-arch für den Bau des
Pakets.
Zeile 11 zeigt eine der mächtigsten Eigenschaften des Paketsystems von Debian. Pakete können auf verschiedene Arten miteinander in Beziehung stehen. Neben Depends (hängt ab von) gibt es noch die Beziehungsfelder Recommends (empfiehlt), Suggests (schlägt vor), Pre-Depends (setzt voraus), Breaks (beschädigt), Conflicts (kollidiert mit), Provides (enthält) und Replaces (ersetzt).
Die verschiedenen Paketverwaltungswerkzeuge verhalten sich normalerweise bei
der Behandlung dieser Beziehungen gleich; wenn nicht, wird dies erklärt (siehe
dpkg(8), dselect(8), apt(8),
aptitude(1) usw.).
Und das bedeuten die Abhängigkeiten:
Depends
Das Paket wird erst installiert, wenn die hier aufgelisteten Pakete ebenfalls installiert sind. Benutzen Sie dies, wenn ihr Programm ohne ein bestimmtes Paket überhaupt nicht läuft (oder schwere Schäden verursacht).
Recommends
Benutzen Sie dies für Pakete, die nicht absolut notwendig sind, die aber
typischerweise mit Ihrem Programm verwendet werden. Wenn ein Benutzer Ihr
Programm installiert, fragen wahrscheinlich alle Frontends nach, ob die
empfohlenen Pakete auch installiert werden sollen. Aptitude und
apt-get installieren alle empfohlenen Pakete zusammen mit Ihrem
Paket (aber der Benutzer kann diese Voreinstellung außer Kraft setzen).
Dpkg ignoriert dieses Feld.
Suggests
Benutzen Sie dies für Pakete, die mit Ihrem Programm gut zusammenarbeiten,
aber absolut nicht notwendig sind. Wenn ein Benutzer Ihr Programm installiert,
fragen wahrscheinlich alle Frontends nach, ob die vorgeschlagenen Pakete auch
installiert werden sollen. Aptitude kann so konfiguriert werden,
dass es vorgeschlagene Pakete zusammen mit Ihrem Paket installiert, aber dies
ist nicht die Voreinstellung.Dpkg und apt-get
ignorieren dieses Feld.
Pre-Depends
Dies ist 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 nur,
nachdem auf der Mailingliste debian-devel@lists.debian.org
darüber diskutiert wurde. Lies: Verwenden Sie es überhaupt nicht. :-)
Conflicts
Das Paket wird nicht installiert, bevor alle Pakete, mit denen es kollidiert, entfernt wurden. Benutzen Sie dies, wenn ihr Programm überhaupt nicht läuft oder schwere Probleme verursacht, solange ein bestimmtes Paket installiert ist.
Breaks
Wenn dieses Paket installiert wird, werden alle aufgeführten Pakete als beschädigt markiert. Normalerweise hat ein Eintrag unter Breaks einen Versionseintrag mit dem Vergleich »früher als«. Die Lösung ist üblicherweise, dass die aufgelisteten Pakete von den höhergradigen Paketverwaltungswerkzeugen aktualisiert werden.
Provides
Für einige Paketarten mit mehreren Alternativen wurden virtuelle Namen
definiert. 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.
Replaces
Benutzen Sie dies, wenn Ihr Paket Dateien eines anderen Pakets überschreibt oder ein anderes Paket vollständig ersetzt (wird zusammen mit Conflicts benutzt). Dateien der genannten Pakete werden mit den Dateien aus Ihrem Paket überschrieben.
All diese Felder haben eine einheitliche Syntax. Es ist jeweils eine durch Kommata getrennte Liste der Paketnamen. Diese Paketnamen können auch aus einer Liste von alternativen Paketnamen bestehen, die durch senkrechte Striche »|« (»pipe«-Zeichen) getrennt werden.
Die Anwendung der Felder kann auf bestimmte Versionen eines genannten Pakets beschränkt werden. Diese Versionen werden in Klammern nach jedem einzelnen Paketnamen aufgeführt und müssen einen Vergleich aus der folgenden Liste enthalten, gefolgt von der Versionsnummer. Die erlaubten Vergleiche sind <<, <=, =, >= und >> für strikt niedriger, niedriger oder gleich, genau gleich, höher oder gleich und strikt höher. Ein 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)
Die letzten Merkmale, die Sie kennen sollten, sind
${shlibs:Depends}, ${perl:Depends},
${misc:Depends} usw. Diese Einträge werden durch die Liste
ersetzt, die von anderen debhelper-Komponenten erstellt wurde,
während der Befehl dh_gencontrol(1) ausgeführt wird.
Nachdem Ihr Paket gebaut und in das temporäre Verzeichnis installiert wurde,
untersucht dh_shlibdeps(1) die Binärdateien und Bibliotheken auf
Abhängigkeiten von Laufzeitbibliotheken und stellt fest, in welchen Paketen
diese enthalten sind, beispielsweise libc6 oder
xlib6g. Diese Liste von Laufzeitbibliotheken, von denen Ihr
Programm abhängt, wird für ${shlibs:Depends} benutzt.
Die Paketliste, die von dh_perl(1) erzeugt wurde, wird für
${perl:Depends} verwendet.
Einige debhelper-Befehle können eine Abhängigkeit von einem
anderen Paket im erzeugten Paket bewirken. Die Liste solcher benötigten
Pakete wird für ${misc:Depends} benutzt.
Nach all diesen Erklärungen können wir das Feld Depends aber
exakt so belassen, wie es jetzt ist und eine weitere Zeile dahinter einfügen,
in der »Suggests: file« steht, weil gentoo einige
Funktionen des Pakets file nutzen kann.
Zeile 12 enthält eine Kurzbeschreibung. Bei den meisten Leuten sind die Terminalzeilen 80 Zeichen breit, also sollte die Kurzbeschreibung nicht länger als etwa 60 Zeichen sein. Ich ändere es in "fully GUI-configurable, two-pane X file manager".
In die Zeile 13 kommt eine ausführliche Beschreibung. Sie sollte aus einem kleinen Text bestehen, der mehr über das Paket verrät. Die erste Spalte jeder Zeile muss 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.
Lassen Sie uns zwischen die Zeilen 6 und 7 die Felder Vcs-*
einsetzen, die in der Entwickler-Referenz,
6.2.5. »Version Control System location« beschrieben sind. Wir
nehmen an, dass das Paket gentoo im Git-Service von Debian Alioth
unter git://git.debian.org/git/collab-maint/gentoo.git zu finden
ist.
Zum Schluss ist dies die aktualisierte Datei control:
1 Source: gentoo
2 Section: x11
3 Priority: optional
4 Maintainer: Josip Rodin <joy-mg@debian.org>
5 Build-Depends: debhelper (>= 7.0.5), xlibs-dev, libgtk1.2-dev, libglib1.2-dev
6 Standards-Version: 3.8.4
7 Vcs-Git: git://git.debian.org/git/collab-maint/gentoo.git
8 Vcs-browser: http://git.debian.org/?p=collab-maint/gentoo.git
9 Homepage: http://www.obsession.se/gentoo/
10
11 Package: gentoo
12 Architecture: any
13 Depends: ${shlibs:Depends}, ${misc:Depends}
14 Suggests: file
15 Description: fully GUI-configurable, two-pane X file manager
16 gentoo is a two-pane file manager for the X Window System. gentoo lets the
17 user do (almost) all of the configuration and customizing from within the
18 program itself. If you still prefer to hand-edit configuration files,
19 they're fairly easy to work with since they are written in an XML format.
20 .
21 gentoo features a fairly complex and powerful file identification system,
22 coupled to a object-oriented style system, which together give you a lot
23 of control over how files of different types are displayed and acted upon.
24 Additionally, over a hundred pixmap images are available for use in file
25 type descriptions.
26 .
29 gentoo was written from scratch in ANSI C, and it utilises the GTK+ toolkit
30 for its interface.
(Die Zeilennummerierung habe ich hinzugefügt.)
copyright
In dieser Datei stehen Informationen über die Herkunft des Pakets, das
Copyright und die Lizenz. Die Debian-Richtlinien,
12.5 »Copyright information« schreiben keine bestimmte Form vor,
aber den benötigten Inhalt. Sie können auch DEP-5: »Machine-parseable
debian/copyright« zu Rate ziehen.
Dh_make kann eine Vorlage für die Datei copyright
erzeugen. Verwenden Sie hier die Option »--copyright gpl2«, um
eine Vorlage für das Paket gentoo zu erhalten, das unter GPL-2
veröffentlicht wurde.
Sie müssen hier fehlende Informationen eintragen, beispielsweise die Quelle,
von der Sie das Paket bezogen haben, die tatsächlichen Copyright-Vermerke und
die Lizenz, damit die Datei vollständig ist. Bei den verbreiteten Lizenzen
von freier Software wie GNU GPL-1, GNU GPL-2, GNU GPL-3, LGPL-2, LGPL-2.1,
LGPL-3, GNU FDL-1.2, GNU FDL-1.3, Apache-2.0 oder der Artistic license können
Sie auf die entsprechende Datei im Verzeichnis
/usr/share/common-licenses/ verweisen, das auf jedem Debian-System
existiert. Anderenfalls müssen Sie die vollständige Lizenz einfügen.
Zusammengefasst sollte die Datei copyright von gentoo
so aussehen:
1 Format-Specification: http://svn.debian.org/wsvn/dep/web/deps/dep5.mdwn?op=file&rev=135
2 Name: gentoo
3 Maintainer: Josip Rodin <joy-mg@debian.org>
4 Source: http://sourceforge.net/projects/gentoo/files/
5
6 Copyright: 1998-2010 Emil Brink <emil@obsession.se>
7 License: GPL-2+
8
9 Files: icons/*
10 Copyright: 1998 Johan Hanson <johan@tiq.com>
11 License: GPL-2+
12
13 Files: debian/*
14 Copyright: 1998-2010 Josip Rodin <joy-mg@debian.org>
15 License: GPL-2+
16
17 License: GPL-2+
18 This program is free software; you can redistribute it and/or modify
19 it under the terms of the GNU General Public License as published by
20 the Free Software Foundation; either version 2 of the License, or
21 (at your option) any later version.
22 .
23 This program is distributed in the hope that it will be useful,
24 but WITHOUT ANY WARRANTY; without even the implied warranty of
25 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
26 GNU General Public License for more details.
27 .
28 You should have received a copy of the GNU General Public License along
29 with this program; if not, write to the Free Software Foundation, Inc.,
30 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
31 .
32 On Debian systems, the full text of the GNU General Public
33 License version 2 can be found in the file
34 `/usr/share/common-licenses/GPL-2'.
(Die Zeilennummerierung habe ich hinzugefügt.)
Bitte befolgen Sie das »HOWTO«, das von den FTP-Masters zur Verfügung
gestellt wird und an debian-devel-announce geschickt wurde: http://lists.debian.org/debian-devel-announce/2006/03/msg00023.html.
changelog
Dies ist eine zwingend vorgeschriebene Datei, deren Format in den Debian-Richtlinien,
4.4 »debian/changelog« beschrieben wird. Dieses Format benötigen
dpkg und andere Programme um die Versionsnummer, Revision,
Distribution und die Dringlichkeit Ihres Pakets zu bestimmen.
Für Sie ist die Datei ebenfalls wichtig, weil es sinnvoll ist, alle von Ihnen
vorgenommenen Änderungen zu dokumentieren. 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ärpaket als
/usr/share/doc/gentoo/changelog.Debian.gz gespeichert.
Dh_make hat eine Standardvorlage erstellt, die so aussieht:
1 gentoo (0.9.12-1) unstable; urgency=low
2
3 * Initial release (Closes: #nnnn) <nnnn is the bug number of your ITP>
4
5 -- Josip Rodin <joy-mg@debian.org> Mon, 22 Mar 2010 00:37:31 +0100
6
(Die Zeilennummerierung habe ich hinzugefügt.)
In der Zeile 1 stehen der Paketname, die Version, die Distribution und die Dringlichkeit. Der Name muss mit dem Namen des Quellpakets übereinstimmen, die Distribution sollte entweder unstable (oder sogar experimental) sein [16] und die Dringlichkeit sollte nicht auf etwas höheres als low geändert werden. :-)
Zeilen 3-5 sind Log-Einträge, in denen Sie die in dieser Paketrevision
gemachten Änderungen dokumentieren können (hier kommen keine Änderungen des
ursprünglichen Betreuers hinein; für diese Zwecke gibt es eine spezielle
Datei, die von den ursprünglichen Betreuern erstellt wurde und die Sie später
als /usr/share/doc/gentoo/changelog.gz installieren werden). Wir
nehmen an, dass die Nummer Ihres ITP-Fehlerberichts (»Intent To Package«;
Absicht, ein Paket zu erstellen) »12345« lautet. Neue Zeilen
werden direkt über der obersten 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. Closes: #12345
4 * This is my first Debian package.
5 * Adjusted the Makefile to fix $(DESTDIR) problems.
6
7 -- Josip Rodin <joy-mg@debian.org> Mon, 22 Mar 2010 00:37:31 +0100
8
(Die Zeilennummerierung habe ich hinzugefügt.)
Sie können später mehr über Aktualisierungen der Datei
changelog in Weiterentwicklung des
Pakets, Kapitel 9 lesen.
rules
Wir werfen nun einen Blick auf die genauen Regeln, die
dpkg-buildpackage(1) verwenden wird, um das Paket zu bauen. Diese
Datei ist in Wirklichkeit ein weiteres Makefile, aber anders als
die von den ursprünglichen Betreuern mitgelieferten. Im Unterschied zu den
anderen Dateien im Verzeichnis debian ist diese Datei als
ausführbar gekennzeichnet.
rules
Wie jedes andere Makefile besteht die Datei rules aus
mehreren Targets, deren Regeln bestimmen, wie mit dem Quellcode verfahren wird.
In den Debian-Richtlinien,
4.9 »Main building script: debian/rules« werden die Details
erklärt.
Vereinfachte Erklärungen der Targets sind im Folgenden aufgeführt.
clean-Target: Löschen aller kompilierten, erzeugten und nicht benötigten Dateien im Build-Verzeichnis (erforderlich).
build-Target: Bauen der Quellen zu kompilierten Programmen und formatierten Dokumenten im Build-Verzeichnis (erforderlich).
install-Target: Installieren der Dateien in einen Verzeichnisbaum
unterhalb des Verzeichnisses debian für jedes Binärpaket. Wenn
sie festgelegt wurden, hängen binary*-Targets effektiv von diesem
Target ab (optional).
binary-Target: Erstellt alle Binärpakete (effektiv ist dies die Kombination der binary-arch- und binary-indep-Targets) (erforderlich). [17]
binary-arch-Target: Erstellt Architektur-abhängige (Architecture: any) Binärpakete im übergeordneten Verzeichnis (erforderlich). [18]
binary-indep-Target: Erstellt Architektur-unabhängige (Architecture: all) Binärpakete im übergeordneten Verzeichnis (erforderlich). [19]
get-orig-source-Target: Herunterladen der neuesten Version des Quellpakets von der ursprünglichen Website (optional).
Regeln, die Sie ausführen möchten, werden beim Aufruf als Befehlszeilenargumente angegeben (beispielsweise »./debian/rules build« oder »fakeroot make -f debian/rules binary«). Nach dem Namen des Targets können Sie weitere benötigte Targets, Programme oder Dateien angeben, von der die Ausführung der Regel abhängt. Danach folgt eine beliebige Anzahl von Befehlen, eingerückt mit TAB. Eine neue Regel 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 jetzt wahrscheinlich verwirrt, aber nach der genaueren Betrachtung der
Datei rules, die uns dh_make erstellt hat, wird alles
klar werden. Sie sollten außerdem die Ausgabe von »info make«
für weitere Informationen lesen.
rules
Neuere Versionen von dh_make erzeugen als Vorgabe eine sehr
einfache, doch mächtige Datei rules, indem sie den Befehl
dh verwenden:
1 #!/usr/bin/make -f
2 # -*- makefile -*-
3 # Sample debian/rules that uses debhelper.
4 # This file was originally written by Joey Hess and Craig Small.
5 # As a special exception, when this file is copied by dh-make into a
6 # dh-make output file, you may use that output file without restriction.
7 # This special exception was added by Craig Small in version 0.37 of dh-make.
8
9 # Uncomment this to turn on verbose mode.
10 #export DH_VERBOSE=1
11
12 %:
13 dh $@
(Die Zeilennummerierung habe ich hinzugefügt. In der richtigen
rules-Datei sind die führenden Leerzeichen Tabulatoren.)
Sie sind wahrscheinlich mit ähnlichen Zeilen wie der Zeile 1 aus Shell- oder
Perlskripten vertraut. Sie teilt dem Betriebssystem mit, dass das Skript mit
/usr/bin/make verarbeitet werden soll.
In Zeile 10 kann der Kommentar entfernt werden, damit die Variable
DH_VERBOSE auf 1 gesetzt wird. Dann gibt der Befehl
dh aus, welche dh_*-Befehle vom Befehl
dh ausgeführt werden. Sie können hier auch die Zeile
»export DH_OPTIONS=-v« hinzufügen. Dann gibt jeder
dh_*-Befehl aus, welche Befehle von jedem dh_*-Befehl
ausgeführt werden. Das hilft Ihnen dabei, zu verstehen, was genau hinter den
Kulissen dieser einfachen rules-Datei passiert. So können Sie
Probleme besser finden. Das neue dh ist ein zentraler Bestandteil
der debhelper-Werkzeuge und versteckt nichts vor Ihnen.
In den Zeilen 12 und 13 wird die gesamte Arbeit erledigt. Das Prozentzeichen
steht für ein beliebiges Target, das dann lediglich ein Programm aufruft,
nämlich dh mit dem Namen des Targets. [20] Der Befehl dh ist
ein Skript, das abhängig vom übergebenen Argument die entsprechenden
Sequenzen von dh_*-Programmen ausführt. [21]
»debian/rules clean« ruft »dh clean« auf, das wiederum das Folgende ausführt:
dh_testdir
dh_auto_clean
dh_clean
»debian/rules build« ruft »dh build« auf, das wiederum das Folgende ausführt:
dh_testdir
dh_auto_configure
dh_auto_build
dh_auto_test
»fakeroot debian/rules binary« ruft »fakeroot dh binary« auf, das wiederum das Folgende ausführt [22]:
dh_testroot
dh_prep
dh_installdirs
dh_auto_install
dh_install
dh_installdocs
dh_installchangelogs
dh_installexamples
dh_installman
dh_installcatalogs
dh_installcron
dh_installdebconf
dh_installemacsen
dh_installifupdown
dh_installinfo
dh_pysupport
dh_installinit
dh_installmenu
dh_installmime
dh_installmodules
dh_installlogcheck
dh_installlogrotate
dh_installpam
dh_installppp
dh_installudev
dh_installwm
dh_installxfonts
dh_bugfiles
dh_lintian
dh_gconf
dh_icons
dh_perl
dh_usrlocal
dh_link
dh_compress
dh_fixperms
dh_strip
dh_makeshlibs
dh_shlibdeps
dh_installdeb
dh_gencontrol
dh_md5sums
dh_builddeb
»fakeroot debian/rules binary-arch« ruft »fakeroot dh binary-arch« auf, das wiederum dieselbe Sequenz ausführt wie »fakeroot dh binary«, allerdings wird an jeden Befehl die Option »-a« angehängt.
»fakeroot debian/rules binary-indep« ruft »fakeroot dh
binary-indep« auf, das wiederum fast dieselbe Sequenz ausführt wie
»fakeroot dh binary«, allerdings wird an jeden Befehl die Option
»-i« angehängt und die Befehle dh_strip,
dh_makeshlibs und dh_shlibdeps weggelassen.
Die Funktion der dh_*-Befehle erschließt sich aus den Namen fast
von selbst. [23] Es gibt
einige wenige, die hier (stark) vereinfacht erklärt werden sollen. Dafür
wird eine typische Build-Umgebung vorausgesetzt, basierend auf einem
Makefile. [24]
dh_auto_clean führt normalerweise das Folgende aus, wenn ein
Makefile existiert und das Target distclean enthält.
[25]
make distclean
dh_auto_configure führt normalerweise das Folgende aus, wenn die
Datei configure existiert (Argumente zur besseren Lesbarkeit
abgekürzt).
./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var ...
dh_auto_build führt normalerweise das Folgende aus, um das erste
Target des Makefile auszuführen, falls dieses existiert.
make
dh_auto_test führt normalerweise das Folgende aus, wenn ein
Makefile mit dem Target test existiert. [26]
make test
dh_auto_install führt normalerweise das Folgende aus, wenn ein
Makefile mit dem Target install existiert (Zeile zur
besseren Lesbarkeit umgebrochen).
make install \
DESTDIR=/Pfad/zum/Paket_Version-Revision/debian/Paket
Targets, die den Befehl fakeroot erfordern, enthalten
dh_testroot. Wenn Sie diesen Befehl benutzen und nicht vorgeben,
»root« zu sein, wird er mit einer Fehlermeldung beendet.
Das Wichtigste, was Sie über die Datei rules wissen müssen, die
von dh_make erzeugt wurde, ist, dass sie lediglich ein Vorschlag
ist. Sie funktioniert für die meisten Pakete, aber für etwas kompliziertere
Pakete sollten Sie sich nicht scheuen, sie für Ihre Zwecke umzuschreiben. Das
Einzige, was Sie nicht ändern dürfen, sind die Namen der Regeln, weil alle
Werkzeuge diese Namen verwenden und sie von den Debian-Richtlinien vorgegeben
sind.
Obwohl »install« kein erforderliches Target ist, wird es
unterstützt. »fakeroot dh install« verhält sich wie
»fakeroot dh binary«, stoppt aber nach dh_fixperms.
rules
Es gibt viele Arten, die rules-Datei anzupassen, die den neuen
Befehl dh verwendet.
Der Befehl »dh $@« kann wie folgt angepasst werden. [27]
Unterstützung des Befehls dh_pysupport hinzufügen (Die beste
Wahl für Python). [28]
Installieren Sie das Paket python-support in
»Build-Depends«.
Verwenden Sie »dh $@« wie sonst auch (Dies ist die Voreinstellung).
Hiermit werden Python-Module mit dem Framework python-support
bearbeitet.
Unterstützung des Befehls dh_pycentral hinzufügen.
Installieren Sie das Paket python-central in
»Build-Depends«.
Verwenden Sie stattdessen »dh --with python-central $@«.
Hierdurch wird auch der Befehl dh_pysupport deaktiviert.
Hiermit werden Python-Module mit dem Framework python-central
bearbeitet.
Unterstützung des Befehls dh_installtex hinzufügen.
Installieren Sie das Paket tex-common in
»Build-Depends«.
Verwenden Sie stattdessen »dh --with tex $@«.
Hiermit werden Type-1-Schriften, Muster für Silbentrennung oder Formate für TeX registriert.
Unterstützung der Befehle dh_quilt_patch und
dh_quilt_unpatch hinzufügen.
Installieren Sie das Paket quilt in
»Build-Depends«.
Verwenden Sie stattdessen »dh --with quilt $@«.
Hiermit werden Patches auf die ursprünglichen Quellen angewendet und auch
wieder rückgängig gemacht. Dafür werden Dateien aus dem Verzeichnis
debian/patches für das Quellpaketformat 1.0
verwendet.
Dies wird nicht benötigt, wenn Sie das neue Quellpaketformat 3.0 (quilt) benutzen.
Unterstützung des Befehls dh_dkms hinzufügen.
Installieren Sie das Paket dkms in »Build-Depends«.
Verwenden Sie stattdessen »dh --with dkms $@«.
Hiermit wird die korrekte Verwendung von DKMS durch das Kernelmodul-Paket sichergestellt.
Unterstützung der Befehle dh_autotools-dev_updateconfig und
dh_autotools-dev_restoreconfig hinzufügen.
Installieren Sie das Paket autotools-dev in
»Build-Depends«.
Verwenden Sie stattdessen »dh --with autotools-dev $@«.
Hiermit werden die Dateien config.sub und
config.guess aktualisiert und wiederhergestellt.
Unterstützung der Befehle dh_autoreconf und
dh_autoreconf_clean hinzufügen.
Installieren Sie das Paket dh-autoreconf in
»Build-Depends«.
Verwenden Sie stattdessen »dh --with autoreconf $@«.
Hiermit werden die Dateien des GNU-Build-Systems aktualisiert und nach dem Bau wiederhergestellt.
Unterstützung der Vervollständigung in der bash hinzufügen.
Installieren Sie das Paket bash-completion in
»Build-Depends«.
Verwenden Sie stattdessen »dh --with bash-completion $@«.
Hiermit wird die Vervollständigung durch bash unter Verwendung
der Konfigurationsdatei in debian/Paket.bash-completion
installiert.
Bei Quellen, die die Autotools benutzen, verwenden Sie eine Kombination des oben genannten wie »dh --with autotools-dev --with autoreconf $@«, um das aktuellste GNU-Build-System zu benutzen.
Viele dh_*-Befehle, die vom neuen dh-Befehl
aufgerufen werden, können durch entsprechende Konfigurationsdateien im
debian-Verzeichnis angepasst werden. Siehe Andere Dateien unter debian/, Kapitel 5 sowie die
Handbuchseite jedes Befehls für Anpassungen dieser Merkmale.
Einige dh_*-Befehle, die vom neuen dh-Befehl
aufgerufen werden, erfordern beim Aufruf Argumente, benötigen zusätzliche
Befehle oder müssen ganz ausgelassen werden. In solchen Fällen können Sie
ein override_dh_foo-Target mit der entsprechenden Regel
in der Datei rules erstellen, das nur für den Befehl
dh_foo gilt, den Sie ändern wollen. Im Grunde
bedeutet das nur »führe stattdessen mich aus«. [29]
Bitte beachten Sie, dass die dh_auto_*-Befehle dazu tendieren,
mehr als das zu tun, was als (stark) vereinfachte Erklärung besprochen wurde,
damit auch die Sonderfälle berücksichtigt werden. Die Verwendung eines
vereinfachten äquivalenten Befehls statt der dh_auto_*-Befehle in
den override_dh_*-Targets ist allerdings keine gute Idee, weil
dadurch intelligente Funktionen von debhelper ausgehebelt werden
können. Die einzige Ausnahme ist das Target
override_dh_auto_clean.
Wenn Sie systemweite Konfigurationsdaten für das Paket gentoo im
Verzeichnis /etc/gentoo statt dem üblichen Verzeichnis
/etc speichern wollen, können Sie das von
dh_auto_configure vorgegebene Argument
--sysconfig=/etc für den Befehl ./configure wie
folgt überschreiben. [30]
override_dh_auto_configure:
dh_auto_configure -- --sysconfig=/etc/gentoo
Die nach dem -- übergebenen Argumente werden zu den vorgegebenen
Argumenten des automatisch ausgeführten Programms hinzugefügt, um sie zu
überschreiben. Die Benutzung des Befehls dh_auto_configure ist
besser als der direkte Aufruf von ./configure, weil in diesem Fall
lediglich das Argument --sysconfig überschrieben wird und andere,
sehr wohl beabsichtigte, Argumente für den Befehl ./configure
erhalten bleiben.
Falls das Makefile der Quellen von gentoo zum Bauen
explizit das Target build benötigt, [31], können Sie ein Target namens
override_dh_auto_build erstellen, um dies möglich zu machen.
override_dh_auto_build:
dh_auto_build -- build
Hiermit wird sichergestellt, dass $(MAKE) mit allen voreingestellten Argumenten
des Befehls dh_auto_build ausgeführt und dabei das Argument
build übergeben wird.
Falls das Makefile der Quellen von gentoo zum
Aufräumen für das Debianpaket explizit das Target packageclean
benötigt statt der Targets distclean oder clean der
Datei Makefile, können Sie ein Target namens
override_dh_auto_clean erstellen, um dies möglich zu machen.
override_dh_auto_clean:
$(MAKE) packageclean
Falls das Makefile der Quellen von gentoo das Target
test enthält, das Sie im Paketbau-Prozess für Debian nicht
ausführen wollen, können Sie ein leeres Target namens
override_dh_auto_test erstellen, um dies zu übergehen.
override_dh_auto_test:
Wenn gentoo eine unübliche ursprüngliche Changelog-Datei namens
FIXES enthält, wird diese standardmäßig von
dh_installchangelogs nicht installiert. Der Befehl
dh_installchangelogs braucht den Namen FIXES als
Argument, um die Datei zu installieren. [32]
override_dh_installchangelogs:
dh_installchangelogs FIXES
Wenn Sie den neuen dh-Befehl benutzen, wird es schwierig, die
genauen Effekte von expliziten Targets wie den in Targets
der Datei rules, Abschnitt 4.4.1 aufgelisteten zu verstehen.
Eine Ausnahme stellt get-orig-source dar. Bitte beschränken Sie
daher - soweit möglich - explizite Targets auf solche mit den Namen
override_dh_* sowie vollständig davon unabhängige.
[ zurück ] [ Inhalt ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ weiter ]
Anleitung für zukünftige Debian-Betreuer
Diese Übersetzung wird derzeit aktualisiert. Teile beruhen auf Version 1.2.3 vom 18. Januar 2005, die aktuelle Version ist 1.2.25, 2010-12-21 14:06:56 UTCjoy-mg@debian.orgtoddy@debian.orgmail@erikschanze.deblade@debian.org