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


Anleitung für zukünftige Debian-Betreuer
Kapitel 4 - Benötigte Dateien im Verzeichnis 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.


4.1 Die Datei 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.

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.

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:

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


4.2 Die Datei 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.


4.3 Die Datei 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.


4.4 Die Datei 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.


4.4.1 Targets der Datei 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.

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.


4.4.2 Die vorgegebene Datei 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]

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]

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.


4.4.3 Anpassungen der Datei rules

Es gibt viele Arten, die rules-Datei anzupassen, die den neuen Befehl dh verwendet.

Der Befehl »dh $@« kann wie folgt angepasst werden. [27]

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-22 12:44:34 UTC

Josip Rodin joy-mg@debian.org

Übersetzung von Tobias Quathamer toddy@debian.org
Erik Schanze mail@erikschanze.de
und Eduard Bloch blade@debian.org