Kapitel 2. Erste Schritte

Inhaltsverzeichnis

2.1. Arbeitsschritte beim Bau von Debian-Paketen
2.2. Ihr Programm auswählen
2.3. Besorgen Sie sich das Programm und probieren Sie es aus
2.4. Einfache Bausysteme
2.5. Beliebte portable Bausysteme
2.6. Name und Version des Pakets
2.7. Einrichten von dh_make
2.8. Das erste nicht native Debian-Paket
2.9. Das erste native Debian-Paket

Lassen Sie uns anfangen, indem Sie Ihr eigenes Paket erstellen (oder, noch besser, ein vorhandenes übernehmen).

Falls Sie ein Debian-Paket mit einem Programm von (anderen) Originalautoren erstellen, ist ein Teil der typischen Arbeitsschritte des Debian-Paketbaus die Erstellung mehrerer speziell benannter Dateien für jeden Schritt, wie folgt:

Bitte beachten Sie, dass das Zeichen, das Paket und Version trennt, von - (Bindestrich) im Tarball-Namen zu _ (Unterstrich) im Debian-Paketdateinamen geändert wurde.

Im obigen Dateinamen wird der Paket-Teil durch den Paketnamen, der Version-Teil durch die Version der Originalautoren, der Revision-Teil durch die Debian-Revision und der arch-Teil mit der Paketarchitektur, wie dies in dem »Debian Policy Manual« festgelegt ist, ersetzt. [5]

Falls Sie stattdessen ein Debian-spezifisches Paket ohne (andere) Originalautoren erstellen, ist der typische Arbeitsablauf bei der Paketerstellung einfacher.

  • Erstellen Sie ein natives Debian-Quellpaket im Format 3.0 (native) mit einer einzelnen komprimierten Tar-Datei, in der alle Dateien enthalten sind.

    • Paket_Version.tar.gz
    • Paket_Version.dsc
  • Bauen Sie Debian-Binärpakete aus den nativen Debian-Quellpaketen.

    • Paket_Version_Arch.deb

Jeder Schritt dieser Übersicht wird in späteren Abschnitten mit detaillierten Beispielen erklärt.

Sie haben sich wahrscheinlich schon ein Paket ausgesucht, das Sie erstellen wollen. Zuerst müssen Sie überprüfen, ob das Paket bereits in der Distribution existiert, indem Sie das Folgende benutzen.

Wenn es das Paket schon gibt, na, dann installieren Sie es! :-) Falls es verwaist (»orphaned«) wurde (wenn als Betreuer »Debian QA Group« eingetragen ist), dann können Sie es übernehmen, wenn es noch verfügbar ist. Sie können auch ein Paket adoptieren, dessen Betreuer einen »Request for Adoption« (RFA) geschrieben hat. [6]

Es gibt mehrere Ressourcen zur Paketeigentümerschaft

Als wichtige Randbemerkung sei darauf hingewiesen, dass Debian bereits für fast alle Arten von Programmen Pakete enthält und die Anzahl der Pakete im Debian-Archiv wesentlich größer ist als die der Mitwirkenden mit Berechtigung zum Hochladen. Daher werden Beiträge zu Paketen, die bereits im Archiv enthalten sind, von anderen Entwicklern wesentlich mehr gewürdigt (und haben bessere Chancen, gesponsert zu werden) [7]. Sie können auf verschiedene Arten beitragen.

  • Pakete übernehmen, die verwaist wurden, aber aktiv benutzt werden

  • Mitglied in einem Paketierungs-Team werden

  • Fehler von sehr beliebten Paketen sortieren und bewerten

  • Vorbereiten von QA- oder NMU-Uploads

Wenn Sie ein Paket übernehmen möchten, laden Sie sich das Quell-Paket herunter (z. B. mit »apt-get source Paketname«) und nehmen Sie es unter die Lupe. Leider enthält dieses Dokument keine umfassende Anleitung zum Übernehmen von Paketen. Der Vorteil ist, dass schon jemand das Paket für Sie vorbereitet hat und Sie keine Schwierigkeiten haben sollten, herauszufinden, wie das Paket funktioniert. Doch lesen Sie weiter, denn viele der folgenden Ratschläge werden auch für Sie nützlich sein.

Falls das Paket neu ist und Sie es gern in Debian integrieren möchten, gehen Sie wie folgt vor:

  • Zuerst sollten Sie sicher sein, dass das Programm funktioniert und es bereits einige Zeit ausprobiert haben, damit Sie die Nützlichkeit bestätigen können.

  • Überprüfen Sie auf der Site »Arbeit-bedürfende und voraussichtliche Pakete«, dass niemand bereits an diesem Paket arbeitet. Falls noch niemand daran arbeitet, schreiben Sie mit reportbug einen ITP-Fehlerbericht (»Intent To Package«; Absicht, das Paket zu erstellen) an das wnpp-Pseudopaket. Wenn schon jemand an dem Paket arbeitet, nehmen Sie mit ihm Verbindung auf, wenn es nötig ist. Andernfalls finden Sie bestimmt ein anderes interessantes Paket, das von niemandem betreut wird.

  • Die Software muss eine Lizenz haben.

    • Für den Bereich main verlangen die Debian-Richtlinien, dass es die Debian-Richtlinien für Freie Software komplett erfüllt (DFSG) und kein Paket außerhalb von main benötigt, um zu kompilieren oder ausgeführt zu werden. Dies ist der erwünschte Fall.

    • Für den Bereich contrib muss es zu den DFSG konform sein, darf aber ein Paket außerhalb von main für die Kompilierung oder Ausführung erfordern.

    • Für den Bereich non-free darf es gegen Punkte der DFSG verstoßen, es muss aber verteilbar sein.

    • Sind Sie nicht sicher, wohin das Paket gehört, schicken Sie den Lizenztext an debian-legal@lists.debian.org und bitten um Rat.

  • Das Programm sollte keine Sicherheitsprobleme und Betreuungssorgen zum Debian-System hinzufügen.

    • Das Programm sollte gut dokumentiert und der Quellcode verständlich (d.h. nicht verschleiert) sein.

    • Sie sollten den oder die Autoren des Programms kontaktieren und sicherstellen, dass sie mit dem Paketieren einverstanden und Debian wohlgesonnen sind. Es ist wichtig, dass die Autoren auch später im Fall von Problemen über das Programm befragt werden können. Versuchen Sie also nicht, aufgegebene Programme zu paketieren.

    • Das Programm sollte sicherlich nicht als »setuid root« laufen, oder noch besser, es sollte für die Ausführung überhaupt keine setuid- oder setgid-Rechte brauchen.

    • Das Programm sollte kein Daemon sein oder in die Verzeichnisse */sbin installiert werden und auch keinen Port als Root öffnen.

Natürlich ist der zuletzt aufgeführt Punkte eher eine Sicherheitsmaßnahme und sollte Sie vor tobenden Benutzern schützen, falls Ihr setuid-Daemon irgendetwas Schlimmes anstellt … Wenn Sie mehr Erfahrungen im Erstellen von Paketen gesammelt haben, können Sie sich auch solche Software paketieren.

Als neuer Betreuer wird Ihnen empfohlen, Erfahrung im Paketieren einfacher Pakete zu sammeln und Ihnen abgeraten, komplizierte Pakete zu erstellen.

  • Einfache Pakete

    • einfaches Binärpaket, arch=all (Sammlung von Daten, wie Hintergrundgraphiken)

    • einfaches Binärpaket, arch=all (in interpretierten Sprachen wie POSIX-Shell geschriebene Programme)

  • Mittel-komplexe Pakete

    • einfaches Binärpaket, arch=any (ELF-Binärprogramme, kompiliert aus Sprachen wie C und C++)

    • mehrere Binärpakete, arch=any+all (Pakete für ELF-Binärprogramme + Dokumentation)

    • Quelle der Originalautoren ist weder im Format tar.gz noch im Format tar.bz2

    • die Quellen der Originalautoren enthalten Inhalte, die nicht verteilt werden dürfen

  • Hochkomplexe Pakete

    • Interpretermodulpakete, die von anderen Paketen verwandt werden

    • generische ELF-Bibliothekspakete, die von anderen Paketen verwandt werden

    • mehrere Binärpakete, darunter ein ELF-Bibliothekspaket

    • Quellpakete mit mehreren Quellen von Originalautoren

    • Kernelmodul-Pakete

    • Kernel-Patch-Pakete

    • jedes Paket mit nicht trivialen Betreuerskripten

Paketieren von hochkomplexen Paketen ist nicht zu schwer, erfordert aber ein bisschen mehr Wissen. Sie sollten spezielle Hilfestellungen für jede komplexe Funktionalität erbitten. Beispielsweise haben einige Sprachen ihre eigenen Unter-Richtliniendokumente:

Es gibt einen alten lateinischen Spruch: fabricando fit faber (Übung macht den Meister). Es wird nachdrücklich empfohlen, zu üben und mit allen Schritten der Debian-Paketierung mit einfachen Paketen zu spielen, während diese Anleitung gelesen wird. Ein trivialer Tarball der Originalautoren ist hello-sh-1.0.tar.gz, der einen guten Startpunkt darstellt. Er wird wie folgt erstellt:[8]

$ mkdir -p hello-sh/hello-sh-1.0; cd hello-sh/hello-sh-1.0
$ cat > hello <<EOF
#!/bin/sh
# (C) 2011 Foo Bar, GPL2+
echo "Hello!"
EOF
$ chmod 755 hello
$ cd ..
$ tar -cvzf hello-sh-1.0.tar.gz hello-sh-1.0

Als Erstes müssen Sie die Originalquellen des Programms finden und herunterladen. Wahrscheinlich haben Sie bereits die Quellcode-Datei von der Homepage des Autors. Quellen freier Unix-Programme sind üblicherweise im Format tar+gzip mit der Erweiterung .tar.gz, im Format tar+bzip2 mit der Erweiterung .tar.bz2 oder im Format tar+xz mit der Erweiterung .tar.xz.Sie enthalten üblicherweise ein Verzeichnis, das Paket-Version genannt ist, sowie alle Quellcode-Dateien darin.

Falls die neueste Version der Quellen über Versionskontrollsysteme wie Git, Subversion oder CVS verfügbar ist, müssen Sie sie mit »git clone«, »svn co« oder »csv co« herunterladen und dann selbst einen Tarball im Format tar+gzip erstellen, indem Sie die Option »--exclude-vcs« verwenden.

Kommt der Quellcode in einem anderen Archivtyp daher (beispielsweise wenn der Dateiname auf .Z oder .zip endet [9]), sollten Sie ihn auch mit den geeigneten Werkzeugen entpacken und neu einpacken.

Falls die Quellen Ihres Programms Inhalte enthalten, die nicht den DFSG genügen, sollten Sie sie auch entpacken, um solche Inhalte zu entfernen, und mit einer geänderten Version der Originalautoren, die dfsg enhält, neu packen.

Als Beispiel verwende ich hier ein Programm namens gentoo, einen GTK+-Dateimanager. [10]

Erstellen Sie ein Unterverzeichnis in Ihrem Home-Verzeichnis namens debian oder deb oder irgendetwas, das Sie passend finden (beispielsweise wäre in diesem Fall nur ~/gentoo völlig in Ordnung). Kopieren Sie das heruntergeladene Archiv dorthin und entpacken Sie es (mit »tar xzf gentoo-0.9.12.tar.gz«). Vergewissern Sie sich, dass es keine Warnmeldungen beim Entpacken gab, nicht mal so genannte irrelevante, da die Entpackwerkzeuge anderer Leute diese Anomalien ignorieren oder auch nicht ignorieren könnten und sie daher beim Entpacken Probleme bekommen könnten. Ihre Shell-Befehlszeile könnte dann wie folgt aussehen:

$ mkdir ~/gentoo ; cd ~/gentoo
$ wget http://www.example.org/gentoo-0.9.12.tar.gz
$ tar xvzf gentoo-0.9.12.tar.gz
$ ls -F
gentoo-0.9.12/
gentoo-0.9.12.tar.gz

Jetzt haben Sie ein neues Unterverzeichnis namens gentoo-0.9.12. Wechseln Sie dorthin und lesen Sie die mitgelieferte Dokumentation aufmerksam durch. Meistens gibt es Dateien mit den Namen README*, INSTALL*, *.lsm oder *.html. Sie müssen eine Anleitung finden, wie man das Programm kompiliert und installiert (meistens wird von einer Installation in das Verzeichnis /usr/local/bin ausgegangen, aber das werden Sie nicht machen. Mehr dazu später in Abschnitt 3.3, „Installation von Dateien in ihr Zielverzeichnis“).

Sie sollten das Paketieren mit einem komplett aufgeräumten (»pristine«, makellosen) Quellcode-Verzeichnis anfangen oder die Quellen einfach frisch entpacken.

Einfache Programme enthalten normalerweise eine Makefile-Datei und können rein durch den Aufruf von »make« kompiliert werden. [11] Einige von ihnen unterstützen »make check«, wodurch die mitgelieferten Selbsttests gestartet werden. Die Installation in das Zielverzeichnis wird üblicherweise mittels »make install« durchgeführt.

Versuchen Sie nun, das Programm zu kompilieren und auszuführen. Stellen Sie sicher, dass es einwandfrei funktioniert und nichts anderes während der Installation oder der Ausführung kaputt macht.

Meistens können Sie außerdem »make clean« (oder besser »make distclean«) ausführen, um im Build-Verzeichnis aufzuräumen. Manchmal gibt es sogar ein »make uninstall«, womit alle installierten Dateien gelöscht werden können.

Viele freie Software-Programme sind in den Sprachen C oder C++ geschrieben. Die meisten von ihnen verwenden Autotools oder CMake, um auf verschiedene Plattformen portierbar zu sein. Diese Bauwerkzeuge müssen zuerst benutzt werden, um das Makefile und andere benötigte Quelldateien zu erzeugen. Anschließend werden solche Programme mit dem üblichen »make; make install« gebaut.

Autotools ist das GNU-Buildsystem, das aus Autoconf, Automake, Libtool und gettext besteht. Sie erkennen solche Quellen an den Dateien configure.ac, Makefile.am und Makefile.in. [12]

Der erste Schritt im Arbeitsablauf der Autotools ist üblicherweise, dass der ursprüngliche Autor »autoreconf -i -f« im Quellenverzeichnis aufruft und die Quellen dann mit den erzeugten Dateien verteilt.

configure.ac-----+-> autoreconf -+-> configure
Makefile.am -----+        |      +-> Makefile.in
src/Makefile.am -+        |      +-> src/Makefile.in
                          |      +-> config.h.in
                      automake
                      aclocal
                      aclocal.m4
                      autoheader

Das Bearbeiten der Dateien configure.ac und Makefile.am erfordert etwas Wissen über autoconf und automake. Siehe »info autoconf« und »info automake«.

Der zweite Schritt im Arbeitsablauf der Autotools ist üblicherweise, dass der Benutzer diese verteilten Quellen erhält und »./configure && make« in den Quellen aufruft, um das Programm zu einem ausführbaren Binärdatei-Befehl zu kompilieren.

Makefile.in -----+                +-> Makefile -----+-> make -> binary
src/Makefile.in -+-> ./configure -+-> src/Makefile -+
config.h.in -----+                +-> config.h -----+
                 |
  config.status -+
  config.guess --+

Sie können in der Datei Makefile viele Dinge ändern, beispielsweise können Sie den voreingestellten Installationsort für Dateien ändern, idem Sie die Befehlszeilenoption »./configure --prefix=/usr« benutzen.

Obwohl es nicht erforderlich ist, kann die Aktualisierung der Datei configure und anderer Dateien mittels »autoreconf -i -f« die Kompatibilität der Quellen verbessern. [13]

CMake ist ein alternatives Build-System. Sie erkennen solche Quellen an der Datei CMakeLists.txt.

Falls die Quellen der Originalautoren als gentoo-0.9.12.tar.gz existieren, können Sie gentoo als (Quell-)Paketnamen und 0.9.12 als die Versionsnummer der Originalautoren verwenden. Diese werden in der Datei debian/changelog verwandt, die auch später in Abschnitt 4.3, „changelog beschrieben wird.

Obwohl dieser einfache Ansatz meistens funktioniert, könnte es sein, dass Sie den Paketnamen und die Versionsnummer der Originalautoren durch Umbenennen der Originalquellen anpassen müssen, damit dies den Debian-Richtlinien und bestehenden Konventionen genügt.

Sie müssen den Paketnamen so wählen, dass er nur aus Kleinbuchstaben (a-z), Ziffern (0-9), Plus- (+) und Minus- (-) Zeichen und Punkten (.) besteht. Er muss mindestens zwei Zeichen lang sein, mit einem alphanumerischen Zeichen beginnen und darf mit keinem existierenden übereinstimmen. Es empfiehlt sich, die Länge unter 31 Zeichen zu halten. [14]

Falls die Originalautoren einen generischen Ausdruck wie test-suite für den Namen verwenden, ist es eine gute Idee, es umzubenennen, um den Inhalt explizit zu identifizieren und den Namensraum sauber zu halten. [15]

Sie sollten die Versionsnummer der Originalautoren so wählen, dass sie nur aus alphanumerischen Zeichen (0-9A-Za-z), Pluszeichen (+), Tilden (~) und Satzpunkten (.) besteht. Sie muss mit einer Ziffer (0-9) beginnen. [16] Es ist eine gute Idee, die Länge falls möglich innerhalb von 8 Zeichen zu halten. [17]

Falls die Originalautoren kein normales Versionierungsschema wie 2.30.32 sondern eine Art von Datum wie 11Apr29, einen zufälligen Kodenamen oder einen VCS-Hashwert als Teil der Version verwenden, stellen Sie sicher, dass sie das von der Version der Originalautoren entfernen. Diese Informationen können in der Datei debian/changelog festgehalten werden. Falls Sie eine Versionsnummer erfinden müssen, vewrenden Sie das Format YYYYMMDD, wie 20110429, als Versionsnummer der Originalautoren. Das stellt sicher, dass dpkg neuere Versionen korrekt als Upgrades interpretiert. Falls Sie in der Zukunft reibungslose Übergänge zu dem normalen Versionsschemata wie 0.1 sicherstellen müssen, verwenden Sie das stattdessen das Format 0~YYMMDD, wie 0~110429, als Versionsnummer der Originalautoren.

Versionsnummern [18] können mit dpkg(1) wie folgt verglichen werden:

$ dpkg --compare-versions Ver1 Op Ver2

Die Versionsvergleichsregeln können wie folgt zusammengefasst werden:

  • Zeichenketten werden von Anfang bis Ende verglichen.

  • Buchstaben sind größer als Ziffern.

  • Zahlen werden als Ganzzahlen verglichen.

  • Buchstaben werden in ASCII-Sortierreihenfolge verglichen.

  • Es gibt besondere Regeln für Punkt (.), Plus- (+) und Tilde- (~) Zeichen, wie folgt:

    0.0 < 0.5 < 0.10 < 0.99 < 1 < 1.0~rc1 < 1.0 < 1.0+b1 < 1.0+nmu1 < 1.1 < 2.0

Ein schwieriger Fall tritt auf, wenn die Originalautoren gentoo-0.9.12-ReleaseCandidate-99.tar.gz als Vorabveröffentlichung von gentoo-0.9.12.tar.gz veröffentlichen. Sie müssen sicherstellen, dass das Upgrade korrekt funktioniert, indem Sie die Quellen der Originalautoren in gentoo-0.9.12~rc99.tar.gz umbenennen.

Richten Sie die Umgebungsvariablen $DEBEMAIL und $DEBFULLNAME in der Shell ein, damit verschiedene Debian-Wartungswerkzeuge Ihre E-Mail-Adresse und Ihren Namen für Pakete verwenden können. [19]

$ cat >>~/.bashrc <<EOF
DEBEMAIL="Ihre.E-Mail.Adresse@example.org"
DEBFULLNAME="Vorname Nachname"
export DEBEMAIL DEBFULLNAME
EOF
$ . ~/.bashrc

Normale Debian-Pakete sind nicht native Debian-Pakete, die aus Quellen von Originalautoren erzeugt werden. Falls Sie ein nicht natives Debian-Paket von den Quellen der Originalautoren gentoo-0.9.12.tar.gz erstellen wollen, können sie ein erstes nicht natives Debian-Paket dafür mittels des Befehl dh_make wie folgt erstellen:

$ cd ~/gentoo
$ wget http://example.org/gentoo-0.9.12.tar.gz
$ tar -xvzf gentoo-0.9.12.tar.gz
$ cd gentoo-0.9.12
$ dh_make -f ../gentoo-0.9.12.tar.gz

Natürlich ersetzen Sie den Dateinamen mit dem Namen Ihres ursprünglichen Quellcode-Archivs. [20] Siehe dh_make(8) für Details.

Sie sollten irgendeine Ausgabe sehen, die Sie fragt, welche Art Paket Sie erstellen wollen. Gentoo ist ein »single binary package« - es wird nur ein Binärpaket, d.h. eine .deb-Datei erstellt, also wählen Sie die erste Option (mit der »s«-Taste), überprüfen nochmal die Informationen auf dem Bildschirm und bestätigen mit »EINGABE«. [21]

Dieser Aufruf von dh_make erstellt eine Kopie des ursprünglichen Tarballs als gentoo_0.9.12.orig.tar.gz im übergeordneten Verzeichnis, um später die Erstellung eines nicht nativen Debian-Quellpakets mit dem Namen debian.tar.gz zu ermöglichen.

$ cd ~/gentoo ; ls -F
gentoo-0.9.12/
gentoo-0.9.12.tar.gz
gentoo_0.9.12.orig.tar.gz

Bitte beachten Sie zwei entscheidende Merkmale in dem Dateinamen gentoo_0.9.12.orig.tar.gz:

  • Paketname und Version sind durch das Zeichen »_« (Unterstrich) getrennt.

  • Die Zeichenkette .orig wurde vor dem .tar.gz eingefügt.

Beachten Sie außerdem, dass viele Schablonendateien im Quellverzeichnis im Unterverzeichnis debian erstellt werden. Diese werden in Kapitel 4, Benötigte Dateien im Verzeichnis debian und Kapitel 5, Andere Dateien im Verzeichnis debian erklärt. Weiterhin sollte Ihnen klar sein, dass das Paketieren kein vollautomatischer Prozess sein kann. Sie müssen die ursprünglichen Quellen für Debian verändern (siehe Kapitel 3, Den Quellcode verändern). Danach müssen Sie die geeigneten Methoden für den Bau des Debian-Paketes verwenden (Kapitel 6, Bau des Pakets), sie testen (Kapitel 7, Überprüfen des Pakets auf Fehler) und hochladen (Kapitel 9, Das Paket hochladen). Alle diese Schritte werden erläutert.

Wenn Sie versehentlich einige der Schablonendateien gelöscht haben, während Sie sie bearbeitet haben, können Sie diese wiederherstellen, indem Sie erneut dh_make mit der Option --addmissing in einem Debian-Quellverzeichnis aufrufen.

Das Aktualisieren eines existierenden Pakets kann kompliziert werden, weil es eventuell ältere Techniken verwendet. Während Sie die Grundlagen lernen, bleiben Sie bei der Erstellung eines neuen Pakets; weitere Erklärungen werden in Kapitel 8, Aktualisieren des Pakets gegeben.

Bitte beachten Sie, dass die Quellen kein in Abschnitt 2.4, „Einfache Bausysteme“ und Abschnitt 2.5, „Beliebte portable Bausysteme“ beschriebenes Bausystem enthalten müssen. Es könnte eine reine Sammlung von graphischen Daten usw. sein. Die Installation der Dateien könnten rein mit debhelper-Konfigurationsdateien wie debian/install (siehe Abschnitt 5.11, „install) erfolgen.

Falls ein Paket Quelldateien enthält, die Sie nur für Debian betreuen, vielleicht sogar nur für lokale Benutzung, könnte es einfacher sein, es als natives Debian-Paket zu erstellen. Falls Sie Quellen in ~/MeinPaket-1.0 haben, können Sie dafür ein initiales natives Debian-Paket erstellen, indem Sie den folgenden dh_make-Befehl ausführen:

$ cd ~/MeinPaket-1.0
$ dh_make --native

Dann werden das Verzeichnis debian und seine Inhalte genau wie bei Abschnitt 2.8, „Das erste nicht native Debian-Paket“ erstellt. Dies erstellt keinen Tarball, da dies ein natives Debian-Paket ist. Das ist aber auch der einzige Unterschied. Der Rest der Paketierungsaktivitäten ist praktisch identisch.



[4] Für die Debian-Quellpakete im älteren 1.0-Format wird stattdessen Paket_Version-Revision.diff.gz benutzt.

[5] Lesen Sie 5.6.1 "Source", 5.6.7 "Package" und 5.6.12 "Version". Die Paketarchitektur folgt dem Debian Policy Manual, Kapitel 5.6.8 »Architecture« und wird während des Paketbauprozesses automatisch zugewiesen.

[7] Trotzdem gibt es natürlich immer neue Programme, die es wert sind, für Debian paketiert zu werden.

[8] Machen Sie sich keine Sorge um das fehlende Makefile. Sie können den Befehl hello einfach mittels debhelper wie in Abschnitt 5.11, „install oder durch Veränderung der Quellen der Originalautoren installieren, indem Sie ein neues Makefile mit dem Ziel install wie in Kapitel 3, Den Quellcode verändern hinzufügen.

[9] Sie können das Archivformat herausfinden, indem Sie den Befehl file verwenden, wenn die Dateierweiterung nicht genug ist.

[10] Das Programm ist bereits paketiert worden. Die aktuelle Version verwendet die Autotools als Baustruktur und unterscheidet sich signifikant von den folgenden Beispielen, die auf Version 0.9.12 basieren.

[11] Viele moderne Programme kommen mit einem Skript configure, das bei der Ausführung eine für Ihr System angepasstes Makefile erstellt.

[12] Autotools ist zu umfangreich, um in dieser Anleitung berücksichtigt zu werden. Dieser Abschnitt dient nur der Bereitstellung von Schlüsselwörtern und Referenzen. Falls Sie sie benötigen, stellen Sie sicher, dass Sie das Autotools Tutorial und die lokale Kopie der /usr/share/doc/autotools-dev/README.Debian.gz lesen.

[13] Sie können dies automatisieren, indem Sie das Paket dh-autoreconf installieren. Lesen Sie Abschnitt 4.4.3, „Anpassungen der Datei rules.

[14] Die Standardpaketnamenfeldlänge von aptitude beträgt 30. Für mehr als 90% der Pakete ist die Länge des Namens weniger als 24 Zeichen.

[15] Falls Sie Debian-Entwicklerreferenz 5.1. »Neue Pakete« folgen, wird der ITP-Prozess normalerweise solche Dinge abfangen.

[16] Diese strengere Regel sollte Ihnen helfen, verwirrende Namen zu vermeiden.

[17] Die Standardversionsfeldlänge von aptitude beträgt 10. Die Debian-Revision mit einleitendem Bindestrich verwendet typischerweise 2 Zeichen. Für mehr als 80% der Pakete ist die Versionsnummer der Originalautoren weniger als 8 Zeichen lang und die Debian-Revision weniger als 2 Zeichen. Für mehr als 90% der Pakete ist die Versionsnummer der Originalautoren weniger als 10 Zeichen lang und die Debian-Revision weniger als 3 Zeichen.

[18] Versionsnummern können die Versionsnummer der Originalautoren (Version), die Debian-Revision (Revision) oder die Version (Version-Revision) sein. Lesen Sie Abschnitt 8.1, „Neue Debian-Revision“, um zu erfahren, wie die Debian-Revision erhöht wird.

[19] Der folgende Text setzt voraus, dass Sie Bash als Ihre Login-Shell benutzen. Falls Sie eine andere Login-Shell wie beispielsweise die Z-Shell verwenden, benutzen Sie die entsprechenden Konfigurationsdateien statt ~/.bashrc.

[20] Wenn die originalen Quellen das Verzeichnis debian und seinen Inhalt enthalten, rufen Sie den Befehl dh_make mit der zusätzlichen Option --addmissing auf. Das neue Quellformat 3.0 (quilt) ist robust genug, selbst mit solchen Paketen umzugehen. Sie müssen wahrscheinlich die vom Originalautor bereitgestellten Inhalte für Ihr Debian-Paket aktualisieren.

[21] Es gibt hier mehrere Auswahlmöglichkeiten: »s« für »Single binary package« (einzelnes Binärpaket), »i« für »Arch-Independent package« (Architektur-unabhängiges Paket), »m« für »Multiple binary packages« (mehrere Binärpakete), »l« für »Library package« (Bibliothekspaket), »k« für »Kernel module package« (Kernelmodulpaket), »n« für »Kernel patch package« (Kernelpatch-Paket) und »b« für »cdbs«-Pakete. Dieses Dokument konzentriert sich auf den Befehl dh (aus dem Paket debhelper), um ein einzelnes Binärpaket zu erstellen, aber zeigt auch auf, wie es für architekturunabhängige Pakete oder mehrere Binärpakete verwandt werden kann. Das Paket cdbs bietet eine alternative Paketierungs-Skriptinfrastruktur zum Befehl dh und wird in diesem Dokument nicht behandelt.