Anleitung für zukünftige Debian-Maintainer ------------------------------------------ Josip Rodin Übersetzer: Erik Schanze Übersetzer: Eduard Bloch Version 1.2.3, 18. Januar 2005. ------------------------------------------------------------------------------- Copyright-Hinweis ----------------- Copyright (C) 1998-2002 Josip Rodin. Dieses Dokument darf gemäß der GNU General Public License (Version 2 oder höher) verwendet werden. Diesem Dokument liegen die Beispiele der folgenden zwei Dokumente zugrunde: Making a Debian Package (AKA the Debmake-Manual), copyright (C) 1997 Jaldhar Vyas. The New-Maintainer's Debian Packaging Howto, copyright (C) 1997 Will Lowe. ------------------------------------------------------------------------------- Inhalt ------ 1. Zu dieser Übersetzung 1.1. Vorwort 1.2. Mini-Glossar 2. Einstieg, aber richtig! 2.1. Benötigte Programme 2.2. Andere Informationen 3. Erste Schritte 3.1. Ein Programm wählen 3.2. Programm holen und ausprobieren 3.3. Name und Version des Pakets 3.4. Die erste "Debianisierung" 4. Quellcode modifizieren 4.1. Installation in ein Unterverzeichnis 4.2. Unterschiedliche Programmbibliotheken 5. Benötigte Dinge in debian/ 5.1. Die Datei `control' 5.2. Die Datei `copyright' 5.3. Die Datei `changelog' 5.4. Die Datei `rules' 6. Andere Dateien unter debian/ 6.1. README.Debian 6.2. conffiles.ex 6.3. cron.d.ex 6.4. dirs 6.5. docs 6.6. emacsen-*.ex 6.7. init.d.ex 6.8. manpage.1.ex, manpage.sgml.ex 6.9. menu.ex 6.10. watch.ex 6.11. ex.package.doc-base 6.12. postinst.ex, preinst.ex, postrm.ex, prerm.ex 7. "Bau" des Pakets 7.1. Kompletter Neubau 7.2. Schneller Neubau 7.3. Das Kommando `debuild' 7.4. Das `dpatch'-System 7.5. Einbeziehen von `*.orig.tar.gz' beim Hochladen 8. Überprüfung des Pakets auf Fehler 8.1. Die Pakete `lintian' 8.2. Das Programm `mc' 8.3. Das Kommando `debdiff' 8.4. Das Kommando `interdiff' 8.5. Das Kommando `debi' 8.6. Das Paket `pbuilder' 9. Hochladen des Pakets 9.1. Hochladen in das Debian-Archiv 9.2. Hochladen in ein privates Archiv 10. Weiterentwicklung des Pakets 10.1. Eine neue Debian Revision 10.2. Ein neues Upstream-Release (einfach) 10.3. Ein neues Upstream-Release (in Wirklichkeit) 10.4. Die Datei `*.orig.tar.gz' 10.5. Das Kommando `cvs-buildpackage' und ähnliche 10.6. Überprüfen des Upgrades 11. Wo bekommt man Hilfe? A. Beispiele A.1. Einfaches Beispielpaket A.2. Beispielpaket mit `dpatch' und `pbuilder' ------------------------------------------------------------------------------- 1. Zu dieser Übersetzung ------------------------ 1.1. Vorwort ------------ Anmerkung des Übersetzers: Diese Übersetzung baut auf Eduard Blochs Übersetzung der Version 1.0.2 auf. Ich habe bei dieser Übersetzung versucht, mich so eng wie möglich an das englischsprachige Original zu halten. Dennoch musste ich an vielen Stellen Änderungen vornehmen, damit Zusammenhänge verständlich bleiben; es kann deswegen sinnvoll sein, bei Unklarheiten das Original oder die genannten Referenzdokumente zu lesen. Meine eigenen Ergänzungen und Kommentare sind mit "A.d.Ü." gekennzeichnet. Leider können viele englische Begriffe nicht sinnvoll übersetzt werden; in solchen Fällen habe ich versucht, sie so gut wie möglich einzudeutschen. Im Anhang finden Sie ein Glossar, das die Bedeutung der einzelnen Begriffe näher erläutert. Weiterhin übernehme ich keine Verantwortung für Fehler und dadurch verursachte Schäden. Verbesserungen sind jederzeit willkommen. 1.2. Mini-Glossar ----------------- * _Feature_: Eigenschaft, eine spezielle Funktion. * _RTFM_: "read the fucking manual" - "lies das verdammte Handbuch", eine Aufforderung, die zugehörige Dokumentation zu lesen. * _Maintainer_: der zuständige Entwickler eines Softwarepakets. Er "wartet" seine Pakete, korrigiert Fehler usw. * _Policy_, auch _"Policy-Manual"_: eine Sammlung der Vorschriften, an die sich alle Debian-Entwickler halten müssen. Siehe Abschnitt 2.1, `Benötigte Programme'. * _Bug_: Ein Software-Fehler, meist ein Programmierfehler. * _FTBFS_: "Failed to build from source" - das Paket kann aus den Paket-Quellen nicht erstellt werden, meist sind Abhängigkeiten nicht erfüllt. * _Bug Tracking System (BTS)_: Debians System zum Melden und Verwalten von Fehlern. * _Bugfix_: Beheben eines Bugs, meist durch ein berichtigendes Codefragment, sog. Patch. * _Manpage_ oder _Man-Seite_ bzw. _Manual-Seite_: "Bedienungsanleitung" eines Programms, gespeichert in einer gleichnamigen Datei (plus Erweiterung nach Kategorie). Siehe Handbuch, man(1) und die Verweise dort. * _Upstream, Upstream-Autor_: der eigentliche Autor der Software, meist außerhalb der Debian-Distribution. ------------------------------------------------------------------------------- 2. Einstieg, aber richtig! -------------------------- Dieses Dokument versucht, einem typischen Debian-Benutzer und zukünftigen Entwickler in einer verständlichen Sprache die Technik der Paketerstellung für Debian beizubringen, begleitet von funktionierenden Beispielen. Ein alter Römer hat einmal gesagt: _Longum iter est per preaecepta, breve et efficax per exempla!_ (Es ist ein langer Weg mit Regeln, aber ein kurzer und effizienter mit Beispielen!). Eines der Dinge, die Debian zu einer hervorragenden Distribution machen, ist das Paket-System. Auch wenn inzwischen massenhaft Linux-Software im Debian-Format vorhanden ist, muss man manchmal auch Software installieren, die es eben nicht als ".deb"-Paket gibt. Sie fragen sich vermutlich, wie man eigene Pakete erstellt und vielleicht meinen Sie, es sei eine komplizierte Aufgabe. Nun, wenn sie ein blutiger Linux-Neuling sind, dann ist es wirklich hart, aber als Anfänger würden Sie dieses Dokument jetzt nicht lesen. :-) Sie sollten schon ein wenig Kenntnisse über die Unix-Programmierung mitbringen, aber Sie brauchen ganz sicher kein Guru zu sein. Eines ist wohl sicher, um Debian-Pakete richtig zu bauen und zu warten, braucht es Zeit. Um keine Fehler zu machen und damit unser System läuft, muss der Maintainer technisch kompetent sein und fleißig und sorgfältig arbeiten. Dieses Dokument wird jeden kleinen (möglicherweise auch irrelevanten) Schritt erklären, um Ihnen bei der Erstellung des ersten Pakets zu helfen, und Ihnen etwas Erfahrung zu geben im Erstellen neuer Releases dieses, oder vielleicht später anderer Pakete. Aktuelle Versionen dieses Dokuments sollten immer über http://www.debian.org/doc/maint-guide/ oder in dem Paket `maint-guide-de' zu finden sein. 2.1. Benötigte Programme ------------------------ Bevor Sie loslegen können, müssen Sie sicherstellen, dass einige zusätzliche Pakete richtig installiert sind, die für die Entwicklung benötigt werden. Beachten Sie, dass die Liste keine Pakete enthält, die als `essential' oder `required' markiert sind - denn man kann davon ausgehen, dass Sie diese Pakete schon installiert sind. Dieses Dokument wurde überarbeitet für die Pakete in Debian 2.2 (`potato') und 3.0 (`woody'). Die folgenden Pakete sind in der Standard-Installation von Debian enthalten, also werden Sie sie vermutlich schon haben (und zusätzliche Pakete, von denen sie abhängen). Sie können es dennoch überprüfen, z.B. mit `dpkg -s `. * `dpkg-dev' - dieses Paket enthält die Tools, die zum Entpacken, Erstellen und Hochladen der Quell-Pakete benötigt werden. (siehe dpkg-source(1)) * `file' - dieses handliche Programm kann den Typ einer Datei feststellen. (siehe file(1)) * `gcc' - der GNU-C-Compiler ist nötig, wenn Ihr Programm, wie viele andere auch, in der Programmiersprache C geschrieben wurde. (siehe gcc(1)) Dieses Paket wird einige andere Pakete in Ihr System ziehen, wie `binutils', das Programme zum Assemblieren und Linken der Objekt-Dateien enthält (siehe `info binutils` im Paket `binutils-doc') und `cpp', den C-Präprozessor. (siehe cpp(1)) * `g++' - der GNU-C++-Compiler wird benötigt, wenn Ihr Programm in C++ geschrieben wurde. (siehe g++(1)) * `libc6-dev' - die C-Bibliotheken und Header-Dateien, die gcc zum Linken und Erstellen von Objekt-Dateien benötigt. (siehe `info libc` im `glibc-doc' Paket) * `make' - normalerweise wird ein Programm in mehreren Schritten erstellt. Statt wieder und wieder die selben Befehle zu tippen, können Sie das Ganze mit Hilfe dieses Programms und der sog. `Makefile's automatisieren. (siehe `info make`) * `patch' - ein sehr nützliches Programm, das eine sog. diff-Datei, eine Auflistung der Unterschiede im Dateiinhalt (produziert mit dem Programm `diff'), auf die ursprüngliche Datei anwendet und daraus die neue Version erzeugt. (siehe patch(1)) * `perl5' - Perl ist eine der am meisten gebrauchten Skript-Sprachen auf heutigen Unix-ähnlichen Systemen, oft betrachtet als "Unix' Schweizer Offizierskettensäge". (siehe perl(1)) Sie sollten vielleicht auch folgende Pakete installieren: * `autoconf' und `automake' - Viele neue Programme benutzen auch configure-Skripte und Makefile-Vorlagen mit Hilfe dieser Programme, also benötigen Sie diese wahrscheinlich auch. (siehe `info autoconf`, `info automake`) * `dh-make' und `debhelper' - dh-make wird benötigt, um eine Vorlage des Beispiel-Pakets zu erstellen, und es benötigt einige debhelper-Tools für die Paketerstellung. Sie sind nicht zwingend erforderlich, aber für neue Maintainer _sehr_ empfohlen. Es vereinfacht den ersten Einstieg sehr, ebenso die spätere Kontrolle. (siehe dh_make(1), debhelper(1), `/usr/share/doc/debhelper/README') * `devscripts' - dieses Paket enthält einige nützliche Skripte, die für die Maintainer oft sehr hilfreich sein können, aber nicht unbedingt zum Bauen der Pakete benötigt werden. (siehe `/usr/share/doc/devscripts/README.gz') * `fakeroot' - dieses Werkzeug ermöglicht Ihnen, die Identität des "root"s vorzutäuschen, was für einige Teile des Build-Prozesses benötigt wird. (siehe fakeroot(1)) * `gnupg' - ein Programm, mit dem Sie Pakete digital _signieren_ können. Dies ist besonders wichtig, wenn Sie das Paket an andere Leute verteilen wollen und das werden Sie sicher, wenn Ihre Arbeit in die Debian-Distribution aufgenommen wird. (siehe gpg(1)) * `g77' - der GNU-Fortran77-Compiler wird benötigt, wenn Ihr Programm in Fortran geschrieben wurde. * `gpc' - der GNU-Pascal-Compiler wird benötigt, wenn Ihr Programm in Pascal geschrieben wurde. Man sollte an dieser Stelle auch `fp-compiler', den `Free Pascal Compiler` erwähnen, der sich dafür ebenfalls gut eignet. (siehe gpc(1), ppc386(1)) * `xutils' - Programme, die üblicherweise für X11 erstellt wurden, sie dienen zur Generierung von Makefiles aus einem Satz von Makro-Funktionen. (siehe imake(1), xmkmf(1)) * `lintian' - das ist Debians Paket-Prüfer, der Sie über die üblichen Fehler nach der Paketerstellung informiert und die gefundenen Fehler erklärt. (siehe lintian(1), `/usr/share/doc/lintian/lintian.html/index.html') * `pbuilder' - dieses Paket enthält Programme, um eine Chroot-Umgebung aufzubauen und zu betreuen. Beim Bauen eines Debian-Pakets in dieser Chroot-Umgebung wird geprüft, ob die Build-Abhängigkeiten stimmen und das verhindert FTBFS-Fehler. (siehe pbuilder(8) und pdebuild(1)) Es folgen noch _sehr wichtige_ Dokumentationen, die Sie neben diesem Dokument auch lesen sollten: * `debian-policy' - die Policy beinhaltet die Beschreibung der Struktur und des Inhalts eines Archivs, Texte über das Systemdesign, den Filesystem Hierarchy Standard (der beschreibt, wo jede Datei und jedes Verzeichnis ein sollte) etc. Das Wichtigste für Sie ist, sie beschreibt die Anforderungen, die ein Paket erfüllen muss, um in die Distribution aufgenommen zu werden. (siehe /usr/share/doc/debian-policy/policy.html/index.html) * `developers-reference' - für alle Fragen, die nicht ausschließlich technischer Natur der Paketerstellung sind, z.B. über die Struktur des Archivs, wie man Pakete umbenennt, aufgibt, übernimmt, NMUs durchführt, Fehler verwaltet, Hinweise zum guten Paketieren, wie und wo ins Archiv hochlädt etc. (siehe /usr/share/doc/developers-reference/index.en.html) Die kurzen Erklärungen oben dienen nur der Einführung. Bevor Sie weitermachen, sollten Sie die Dokumentation jedes Programms durchlesen, das Sie verwenden werden, zumindest den normalen Umgang. Das mag Ihnen am Anfang überflüssig vorkommen, aber schon bald werden Sie _froh_ darüber sein, sich schon vorher informiert zu haben. Anmerkung: Das Paket `debmake' enthält einige Programme, die dh-make in der Funktionalität sehr ähneln. Die Benutzung von debmake wird hier _nicht_ beschrieben, weil es nicht mehr benutzt werden sollte (_deprecated_). Informationen zu debmake finden Sie im Debmake-Manual (http://www.debian.org/~jaldhar/). 2.2. Andere Informationen ------------------------- Sie können zwei Arten von Paketen erstellen: Binär- und Quell-Pakete. Ein Quell-Paket enthält den Code, aus dem man ein Programm kompilieren kann. Ein Binär-Paket enthält das fertige Programm. Bringen Sie die Begriffe Quellcode und Quell-Paket des Programms nicht durcheinander! Lesen Sie andere Anleitungen, falls die Terminologie nicht klar ist. In Debian bezeichnet der Ausdruck `Maintainer' eine Person, die Pakete baut, `Upstream-Autor' die Person, die das Programm erstellt hat und `Upstream-Maintainer' die Person außerhalb von Debian, die zurzeit das Programm pflegt. Üblicherweise sind `Upstream Autor' und `Upstream-Maintainer' die selbe Person, und manchmal ist es sogar der Maintainer selbst. Wenn Sie also ein Programm erstellen und in Debian integriert sehen möchten, dann können Sie sich ruhig als Maintainer bewerben. Nachdem Sie ein eigenes Paket erstellt haben (oder während Sie gerade dabei sind), möchten Sie vermutlich ein offizieller Debian-Maintainer werden, damit Ihr Paket den Weg in die nächste Distribution findet (wenn das Programm wirklich nützlich ist, warum nicht?). Dieser Prozess ist in der "Developer's Reference" beschrieben; bitte lesen Sie das. ------------------------------------------------------------------------------- 3. Erste Schritte ----------------- 3.1. Ein Programm wählen ------------------------ Sie haben sich wahrscheinlich schon ein Paket ausgesucht, das Sie bauen wollen. Zuerst sollte man am besten überprüfen, ob das Paket nicht bereits in der Distribution existiert. Wenn Sie eine `stable'-Distribution verwenden, sollten Sie am besten über Paket-Such-Seite (http://www.debian.org/distrib/packages.html) nach dem Paket suchen. [A.d.Ü.: Oder von der `unstable'-Distribution die Contents-Datei ziehen und nach bekannten Dateinamen durch'grep'en.] Benutzen Sie die _aktuelle_ `unstable'-Distribution, versuchen Sie es mit diesen Kommandos: dpkg -s Programm dpkg -l '*Programm*' Wenn es das Paket schon gibt, dann installieren Sie es! :-) Wenn es aufgegeben wurde, d.h. wenn als Maintainer "Debian QA Group" eingesetzt ist, dann können Sie es übernehmen. Schauen Sie auf der Liste der abgegebenen Pakete (http://www.debian.org/devel/wnpp/orphaned) und der Liste der zu adoptierenden Pakete (http://www.debian.org/devel/wnpp/rfa_bypackage) nach, welche Pakete dafür zur Verfügung stehen. Wenn Sie ein Paket übernehmen möchten, laden Sie sich das Quell-Paket herunter (z.B. mit `apt-get source `) 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. Wenn das Paket neu ist und Sie es gern in Debian integrieren möchten, gehen Sie wie folgt vor: * Überprüfen Sie auf der Liste der Pakete in Arbeit (http://www.de.debian.org/devel/wnpp/being_packaged), dass niemand bereits an diesem Paket arbeitet. 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. * Das Programm _muss_ eine Lizenz haben, die möglichst `frei' nach den Richtlinien der Debian Free Software Guidelines (http://www.debian.org/social_contract#guidelines). Wenn sie diesen Richtlinien nicht entspricht, aber trotzdem verteilt werden darf, kann das Paket oft noch in die Sektionen `contrib' oder `non-free' aufgenommen werden. Sind Sie sich über die Lizenzfragen nicht sicher, schicken Sie den Lizenz-Text an und bitten um Rat. * 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 Dienst sein, oder in die Verzeichnisse `*/sbin/' installiert werden und auch keinen Port als root öffnen. * Das Programm sollte in einer binären ausführbaren Form erstellt werden, Bibliotheken sind viel schwieriger. * Es sollte gut dokumentiert sein, oder/und der Quellcode sollte verständlich sein. * Sie sollten den Autor des Programms kontaktieren und sicherstellen, dass er mit ihrer Aktion einverstanden ist. Es ist wichtig, dass man den Autor auch später über programmspezifische Probleme fragen kann, versuchen Sie also nicht, ungepflegte/aufgegebene Programme zu packen. * And last but not the least, müssen Sie wissen, wie es funktioniert und damit schon einige Zeit arbeiten. Natürlich sind die aufgeführten Punkte eher Sicherheitsmaßnahmen und sollten Sie vor tobenden Benutzern schützen, falls ihr setuid-Dienst irgendetwas Schlimmes anstellt. Wenn Sie mehr Erfahrungen im Paket-Erstellen gesammelt haben, können Sie sich auch an solchen Paketen versuchen, aber selbst erfahrene Debian-Entwickler fragen schon mal in der debian-mentors-Mailingliste, wenn sie irgendwo Zweifel haben. Und die Leute dort helfen gern. Für weitere Fragen konsultieren Sie die "Developer's Reference". 3.2. Programm holen und ausprobieren ------------------------------------ Als Erstes müssen Sie das Original-Paket des Programms finden und herunterladen. Ich nehme an, dass Sie bereits die Quellcode-Dateien von der Homepage des Autors bezogen haben. Quellen der freien Linux-Programme kommen i.d.R. im tar/gzip-Format, mit der Erweiterung .tar.gz, und enthalten üblicherweise ein Unterverzeichnis, genannt nach dem PROGRAMM-VERSION-Schema, das alle Quellcode-Dateien enthält. Kommt der Quellcode in einem anderen Archivtyp daher (z.B. wenn der Dateiname auf ".Z" oder ".zip" endet), entpacken Sie es mit den entsprechenden Tools oder fragen Sie in der debian-mentors Mailingliste, wie man es richtig entpackt (Tipp: `file archive.extension` versuchen.) Als Beispiel dient hier das Programm namens `gentoo', ein X GTK+-Dateimanager. Das Programm ist bereits verpackt, und wurde wesentlich verändert seit dieser Text geschrieben wurde. Erstellen Sie ein Verzeichnis in Ihrem Home-Verzeichnis, z.B. 'debian' oder 'deb' oder irgendwas anderes, was für Sie geeignet erscheint, etwa `~/gentoo/' in diesem Fall. Kopieren Sie das heruntergeladene Archiv dorthin, und entpacken Sie es, z.B. mit `tar zxvf gentoo-0.9.12.tar.gz`. Vergewissern Sie sich, dass es keine Fehler beim Entpacken gab, nicht mal sog. `irrelevante' Fehler, weil es auf anderen Systemen Probleme geben kann, wenn andere Entpacker bestimmte Anomalien nicht ignorieren. Jetzt haben Sie ein neues Unterverzeichnis, 'gentoo-0.9.12'. Wechseln Sie dorthin und lesen Sie die mitgelieferte Dokumentation _komplett durch_. Meist sind die Dateien mit Namen nach dem Schema `README*', `INSTALL*', `*.lsm' oder `*.html' benannt. Sie müssen eine Anleitung finden, wie man das Programm richtig übersetzt und installiert (meistens wird von einer Installation in `/usr/local/bin/' ausgegangen, aber das wollen Sie nicht. Mehr dazu später in Abschnitt 4.1, `Installation in ein Unterverzeichnis'). Der Prozess ist von Programm zu Programm unterschiedlich, aber viele moderne Programme kommen mit einem `configure'-Skript, das den Quellcode an die Systemumgebung anpasst. Nach dem erfolgreichen Konfigurieren mit `./configure` können die Programme mit `make` kompiliert werden. Einige unterstützen auch `make check`, das zusätzliche Selbsttests durchführt. Die Installation in die Zielverzeichnisse geschieht dann mit `make install`. Versuchen Sie nun, das Programm zu kompilieren und stellen Sie sicher, dass es einwandfrei funktioniert und nichts anderes während der Installation oder der Ausführung kaputt macht. Ebenfalls kann man `make clean` (oder besser `make dist-clean`) ausführen, um im aktuellen Arbeitsverzeichnis aufzuräumen. Manchmal gibt es sogar ein `make uninstall`, womit man alle installierten Dateien löschen kann. 3.3. Name und Version des Pakets -------------------------------- Sie sollten mit einem aufgeräumten oder besser frisch ausgepackten Quellcode-Verzeichnis anfangen. Damit alles richtig funktioniert, sollten Sie den ursprünglichen Namen in Kleinbuchstaben umwandeln. Ebenfalls sollten Sie den Namen zu - verändern. Wenn der Programmname aus mehr als einem Wort besteht, sollten Sie stattdessen ein Wort oder eine Abkürzung verwenden. Zum Beispiel könnte man "John's little editor for X" in johnledx, oder jle4x umbenennen, oder wie auch immer, solange die Länge in einem vernünftigen Rahmen von etwa 20 Zeichen bleibt. Überprüfen Sie auch die exakte Versionsnummer des Programms, die als Versionsnummer des Pakets verwendet wird. Wenn dieses Stück Software keine Nummerierung nach dem Schema X.Y.Z, sondern nach dem Datum verwendet, können Sie dieses Datum mit davor stehenden "0.0" verwenden ("0.0" für den Fall, das sich der `Upstream-Autor' dazu entschließt, eine zukünftige Version mit 1.0 zu nummerieren). In diesem Fall bekommt ein Abzug vom 19. Dezember 1998 eine Versionsnummer wie 0.0.19981219. Einige Programme haben gar keine Versionsnummerierung, in diesem Fall sollten Sie den `Upstream-Maintainer' kontaktieren und eine eindeutige Methode ausarbeiten. 3.4. Die erste "Debianisierung" ------------------------------- Wechseln Sie in das Quell-Verzeichnis des Programms und führen Sie Folgendes aus: dh_make -e ihre.maintainer@adresse -f ../gentoo-0.9.12.tar.gz Natürlich ersetzen Sie "ihre.maintainer@adresse" durch ihre eigene E-Mail-Adresse für den Eintrag im `changelog' sowie anderen Dateien, ebenfalls verwenden Sie den Dateinamen ihres Quellcode-Archivs. (Weitere Details in dh_make(1)). Es werden einige Informationen angezeigt und Sie werden gefragt, welcher Art das Paket sein wird. Gentoo ist ein "single binary package" - es wird eine Binär-Datei und ein .deb-Paket erstellt, also wählen Sie die erste Option mit der `s'-Taste, überprüfen nochmal die Informationen und bestätigen mit . Nach diesem Aufruf von `dh_make' wird eine Kopie des Upstream-Tarballs mit dem Namen `gentoo_0.9.12.orig.tar.gz' im übergeordneten Verzeichnis angelegt, um ein nicht-natives Debian-Quell-Paket mit der Datei `*.diff.gz' erstellen zu können. Beachten Sie zwei wichtige Stellen in dem Dateinamen: * Paketname und Version sind durch das Zeichen "`_'" getrennt. * Es steht "`orig.'" vor "`tar.gz'". Um es noch einmal deutlich zu machen, einem beginnenden Maintainer wird davon abgeraten, komplizierte Pakete zu bauen, z.B.: * mit mehreren Binär-Paketen (`multiple binary packages'), * Bibliotheken (`libraries'), * wenn die Quellen nicht als `tar.gz.' oder `tar.bz2' vorliegen oder * wenn der Quell-Tarball nicht verteilbaren Inhalt hat. Es ist nicht zu schwer, erfordert aber etwas mehr Wissen. Deswegen wird hier nicht näher darauf eingegangen. Beachten Sie, dass `dh_make' nur _ein Mal_ ausgeführt wird und bei späteren Aufrufen nicht sauber funktioniert, wenn Sie es im "debianisierten" Verzeichnis ausführen. Das bedeutet auch, dass Sie bei späteren Updates mit neueren Programm-Versionen anders vorgehen müssen, mehr dazu später in Kapitel 10, `Weiterentwicklung des Pakets'. ------------------------------------------------------------------------------- 4. Quellcode modifizieren ------------------------- Normalerweise installieren sich die Programme in Verzeichnissen unterhalb von `/usr/local/'. Da bei Debian-Paketen dieses Verzeichnis nicht verwendet werden darf und ausschließlich zur Verfügung des lokalen Administrators (oder der User) steht, müssen Sie einen Blick auf den Erstellungsprozess werfen, normalerweise beginnend mit dem Makefile. Das ist das Skript, mit dem make(1) die Arbeit automatisiert. Weitere Details über Makefiles in Abschnitt 5.4, `Die Datei `rules''. Beachten Sie, dass wenn ihr Programm GNU automake(1) und/oder autoconf(1) verwendet, werden Sie die Änderungen in der Datei `Makefile.am' bzw. `Makefile.in' machen müssen, weil jeder Aufruf von automake die Datei `Makefile.in' mit Informationen aus `Makefile.am' neu erzeugt (und die vorhandene Datei `Makefile.in' überschreibt!), genau wie jeder Aufruf von ./configure mit den Daten aus `Makefile.in' das fertige Makefile erzeugt. Änderungen in Dateien `Makefile.am' erfordern einige Kenntnisse über die Funktionsweise von `automake'; mehr darüber finden Sie in der Hilfe `info automake`. Das Bearbeiten von Dateien `Makefile.in' ist dagegen fast genauso einfach wie das Bearbeiten von Makefiles, man muss lediglich bei der Verwendung der Variablen aufpassen, d.h. Strings, die mit `@' umgeben sind, z.B. <@CFLAGS@> oder <@LN_S@>; in diese werden beim Aufruf `./configure` die entsprechenden Werte eingesetzt. Bitte lesen Sie `/usr/share/doc/autotools-dev/README.Debian.gz', bevor Sie weitermachen. Wir können an dieser Stelle nicht auf _alle_ Feinheiten eingehen, denn es würde den Rahmen dieser Anleitung sprengen, aber an dieser Stelle treten auch die wenigsten Probleme auf. 4.1. Installation in ein Unterverzeichnis ----------------------------------------- Die meisten Programme installieren sich in die vorhandene Verzeichnisstruktur, so dass die ausführbaren Binär-Dateien irgendwo in ihrem <$PATH> landen und die Dokumentation an einer der üblichen Positionen. Wenn Sie so vorgehen, wird das Programm aber in Ihr System integriert. Die Paket-Erstellungs-Tools werden es dadurch schwer haben, herauszufinden, welche Dateien zu Ihrem Paket gehören und welche nicht. Deshalb sollten Sie anders verfahren: Installieren Sie das Programm in ein angelegtes Unterverzeichnis von dem aus die Paket-Erstellungs-Tools ein funktionierendes .deb-Paket erzeugen werden. Alles, was dieses Unterverzeichnis enthält, wird später auf das System der Benutzer installiert, mit dem einzigen Unterschied, dass dpkg den Inhalt im Stamm-Verzeichnis auspackt. Dieses Unterverzeichnis wird üblicherweise unterhalb des Verzeichnisses `debian/' im ausgepackten Quellverzeichnis angelegt. Man nennt es `debian/paketname'. Denken Sie daran, auch wenn Sie das Programm in `debian/paketname' installieren, muss es korrekt funktionieren wenn es in das root-Dateisystem übernommen wird, z.B. wenn es aus einem .deb-Paket installiert wird. Sie müssen dafür sorgen, dass beim Erstellen des Pakets keine fest einprogrammierten Werte in den Dateien auftreten wie `/home/me/deb/gentoo-0.9.12/usr/share/gentoo'. Mit Programmen, die GNU `autoconf' benutzen wird es ein leichtes Spiel sein. Die meisten dieser Programme nutzen Makefiles, die es standardmäßig erlauben, das Programm in irgendein Unterverzeichnis zu installieren, ohne zu vergessen, dass /usr der vorschriftsmäßige Präfix ist. `dh_make' wählt die richtigen Kommandos, wenn es feststellt, dass Ihr Programm `autoconf' benutzt, also können Sie diesen Abschnitt vermutlich überspringen. Bei anderen Programmen müssen Sie die entsprechenden Makefiles untersuchen und ggf. anpassen. (A.d.Ü.: Bei einigen Programmen kommt man auch um das Anpassen des Quellcodes nicht herum, wenn z.B. die Pfade zu best. Konfigurationsdateien fest einkompiliert werden). Hier ist der relevante Abschnitt des Makefiles von gentoo: # Where to put binary on 'make install'? BIN = /usr/local/bin # Where to put icons on 'make install'? ICONS = /usr/local/lib/gentoo/ Sie sehen, die Dateien sollen unter `/usr/local' installiert werden, dies ändern Sie zu: # Where to put binary on 'make install'? BIN = $(DESTDIR)/usr/bin # Where to put icons on 'make install'? ICONS = $(DESTDIR)/usr/share/gentoo Sie fragen sich vielleicht, warum in dieses Verzeichnis und nicht in irgendein anderes? Weil Debian-Pakete niemals Dateien unter `/usr/local' ablegen -- dieses Verzeichnis ist für den Systemadministrator reserviert. Debian nutzt stattdessen `/usr'. Eine genauere Beschreibung der Installationsverzeichnisse für Binär-Dateien, Icons und Dokumentationen finden Sie im Filesystem Hierarchy Standard (siehe `/usr/share/doc/debian-policy/fhs/'). Schauen Sie es sich an und lesen Sie die Passagen, die Ihr Paket betreffen könnten. Sie sollten also die Binär-Dateien in `/usr/bin/' anstatt `/usr/local/bin/', die Manpages in `/usr/share/man/man1/' anstatt `/usr/local/man/man1/' installieren. Beachten Sie, dass gentoo's Makefile nicht die Installation einer Manpage vorsieht, doch die Debian Policy verlangt, dass jedes Programm eine hat. Sie schreiben später eine und installieren sie nach `/usr/share/man/man1/'. Manche Programmierer nutzen leider das Makefile nicht, um die Pfade o.ä. variabel zu gestalten. Das bedeutet, dass Sie wahrscheinlich die C-Quelltexte direkt bearbeiten müssen. (A.d.Ü.: Warum? Ganz einfach, weil dieser Pfad beim Kompilieren nirgendwo verwendet wird, müssen Sie davon ausgehen, dass der Autor die Pfadangaben direkt einkodiert hat). Aber wie und wo soll man suchen? Man kann z.B. mit grep -nr -e 'usr/local/lib' --include='*.[c|h]' . das Quellen-Verzeichnis rekursiv durch'grep'en, das Dateien *.c und *.h enthält. Grep wird die Stellen aufzeigen, an den der Pfadname verwendet wurde. (A.d.Ü.: Meine Idee wäre eher: find -regex ".*\.h$\|.*\.c$"|xargs grep -n usr/local/lib | less oder ähnliches). Nun müssen Sie die entsprechenden Dateien bearbeiten und "/usr/local/" durch "/usr/" ersetzen und dabei aufpassen, dass Sie den restlichen Code nicht beschädigen. :-) Wenn alles erledigt ist, sollten Sie das Install-Target im Makefile lokalisieren (Es sollte normalerweise helfen, wenn Sie nach der Zeile, die mit `install:' beginnt, suchen.) und die Verweise auf die Verzeichnisse gegen die Variablen austauschen, die Sie am Anfang definiert haben. Vorher hat das Install-Target so ausgesehen: install: gentoo install ./gentoo $(BIN) install icons/* $(ICONS) install gentoorc-example $(HOME)/.gentoorc Nach unseren Änderungen sieht es so aus: install: gentoo-target install -d $(BIN) $(ICONS) $(DESTDIR)/etc install ./gentoo $(BIN) install -m644 icons/* $(ICONS) install -m644 gentoorc-example $(DESTDIR)/etc/gentoorc Sie haben sicherlich bemerkt, dass es jetzt ein Kommando `install -d' vor allen anderen in der Rule gibt. Das Original-Programm hatte das nicht, weil normalerweise die ursprünglichen Verzeichnisse `/usr/local/bin/' u.a. schon auf dem System existieren, wenn `make install` aufgerufen wird. Weil Sie aber in Ihr eigenes, leeres (oder sogar nicht vorhandenes) Verzeichnis installieren, müssen Sie jedes Verzeichnis vorher anlegen. Sie können noch Weiteres am Ende der Rule anfügen, wie z.B. die Installation einer Dokumentation, die der Upstream-Autor manchmal weglässt. install -d $(DESTDIR)/usr/share/doc/gentoo/html cp -a docs/* $(DESTDIR)/usr/share/doc/gentoo/html Einem aufmerksamen Leser wird auffallen, dass gentoo zu gentoo-target geändert wurde. Das nennt man auch unverlangten Bugfix. ;-) Wo auch immer Sie Änderungen machen, die nicht ausschließlich auf Debian bezogen sind, sollten Sie diese dem Upstream-Maintainer zukommen lassen, damit er diese in zukünftigen Programm-Versionen verwenden kann und sie für alle Anderen nützlich sein können. Und versuchen Sie, dem Upstream entgegen zu kommen, indem Sie keine Debian- oder Linux- (oder eben Unix-) spezifischen Patches senden, sondern gestalten Sie diese portabel. Dadurch kann er Ihre Bugfixes besser übernehmen. Beachten Sie außerdem, dass Sie dem Upstream nicht das ganze Verzeichnis `debian/' schicken müssen. (A.d.Ü.: Speziell hier könnte man dem Upstream mit wenigen C-Kenntnissen helfen, indem man die Pfade variabel macht. D.h. man verändert im Makefile die gcc-Parameter so, dass die Variable an den C-Präprozessor übergeben wird. In dem Programm verwendet man dann statt den festgelegten Pfaden.) 4.2. Unterschiedliche Programmbibliotheken ------------------------------------------ Das ist ein alltägliches Problem: Bibliotheken sind von Plattform zu Plattform verschieden. Z.B. kann ein Makefile einen Verweis auf eine Bibliothek enthalten, die es für Debian nicht gibt. In diesem Fall müssen Sie das Makefile so verändern, dass eine Bibliothek verwendet wird, die es in Debian gibt und den selben Zweck erfüllt. Wenn also im Makefile (bzw. in Makefile.in) eine Zeile wie die folgende vorkommt, und Ihr Programm sich nicht kompiliert lässt: LIBS = -lcurses -lsomething -lsomethingelse ändern Sie sie zum Folgenden und es könnte funktionieren: LIBS = -lncurses -lsomething -lsomethingelse Der Autor ist sich bewusst, dass dies nicht das beste Beispiel ist, weil das Paket `libncurses' einen Symlink `libcurses.so' mitbringt, aber er konnte sich kein besseres ausdenken. Vorschläge sind sehr erwünscht :-) ------------------------------------------------------------------------------- 5. Benötigte Dinge in debian/ ----------------------------- 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. 5.1. Die Datei `control' ------------------------ 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 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: 12 (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 `' herauszufinden, führen Sie objdump -p | 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 Abschnitt 5.4, `Die Datei `rules'' ü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: * Depends: 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. * Recommends: 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. * Suggests: 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. * Pre-Depends: 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. :-) * Conflicts: 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. * Provides: 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. * Replaces: 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 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.) 5.2. Die Datei `copyright' -------------------------- 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 12.6 "Copyright information"). `dh_make' erstellt uns eine Standardvorlage, die etwa so aussieht: 1 This package was debianized by Josip Rodin on 2 Wed, 11 Nov 1998 21:02:14 +0100. 3 4 It was downloaded from 5 6 Upstream Author(s): 7 8 Copyright: 9 10 (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 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 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.) 5.3. Die Datei `changelog' -------------------------- 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 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 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 Kapitel 10, `Weiterentwicklung des Pakets' lesen. 5.4. Die Datei `rules' ---------------------- 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 . 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 # -*- 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 # Uncomment this to turn on verbose mode. 9 #export DH_VERBOSE=1 10 configure: configure-stamp 11 configure-stamp: 12 dh_testdir 13 # Add here commands to configure the package. 14 touch configure-stamp 15 build: build-stamp 16 build-stamp: configure-stamp 17 dh_testdir 18 # Add here commands to compile the package. 19 $(MAKE) 20 #docbook-to-man debian/testpack.sgml > testpack.1 21 touch $@ 22 clean: 23 dh_testdir 24 dh_testroot 25 rm -f build-stamp configure-stamp 26 # Add here commands to clean up after the build process. 27 $(MAKE) clean 28 dh_clean 29 install: build 30 dh_testdir 31 dh_testroot 32 dh_clean -k 33 dh_installdirs 34 # Add here commands to install the package into debian/testpack. 35 $(MAKE) DESTDIR=$(CURDIR)/debian/testpack install 36 # Build architecture-independent files here. 37 binary-indep: build install 38 # We have nothing to do by default. 39 # Build architecture-dependent files here. 40 binary-arch: build install 41 dh_testdir 42 dh_testroot 43 dh_installchangelogs 44 dh_installdocs 45 dh_installexamples 46 # dh_install 47 # dh_installmenu 48 # dh_installdebconf 49 # dh_installlogrotate 50 # dh_installemacsen 51 # dh_installpam 52 # dh_installmime 53 # dh_python 54 # dh_installinit 55 # dh_installcron 56 # dh_installinfo 57 dh_installman 58 dh_link 59 dh_strip 60 dh_compress 61 dh_fixperms 62 # dh_perl 63 # dh_makeshlibs 64 dh_installdeb 65 dh_shlibdeps 66 dh_gencontrol 67 dh_md5sums 68 dh_builddeb 69 binary: binary-indep binary-arch 70 .PHONY: build clean binary-indep binary-arch binary install configure (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 8 bis 9 enthalten Variablen , deren Bedeutung durch die Kurzbeschreibung klar werden sollte. Mehr Informationen über 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 , die in der Policy, Kapitel 10.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 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 Abschnitt 6.8, `manpage.1.ex, manpage.sgml.ex' 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. ------------------------------------------------------------------------------- 6. Andere Dateien unter debian/ ------------------------------- Wie Sie sehen gibt es noch verschiedene weitere Dateien im "debian/"-Unterverzeichnis, von den die meisten mit dem `ex'-Suffix oder Präfix versehen sind, was bedeutet, dass es sich um Beispiele handelt. Schauen Sie sich alle an. Wenn Sie eines dieser Features unbedingt brauchen oder einfach so verwenden möchten: * Lesen Sie die entsprechende Dokumentation (Tipp: Policy-Manual), * ändern Sie die Dateien, wenn nötig, * benennen Sie die Datei um, indem Sie `.ex' entfernen, wenn vorhanden, * benennen Sie die Datei um, indem Sie `ex.' entfernen, wenn vorhanden, * passen Sie die Datei `rules' an, soweit notwendig. Einige dieser Dateien, die am meisten benutzten, werden in den folgenden Abschnitten beschrieben. 6.1. README.Debian ------------------ Alle zusätzlichen Details und nennenswerte Unterschiede zwischen dem Original und ihrer "debianisierten" Version sollten hier dokumentiert werden. `dh_make' erstellt eine Standardvorlage, die etwa so aussieht: gentoo for Debian ----------------- -- Josip Rodin , Wed, 11 Nov 1998 21:02:14 +0100 Da Sie nichts einzutragen haben, kann die Datei ruhig gelöscht werden. 6.2. conffiles.ex ----------------- Eine der ärgerlichsten Sachen bei Software ist es, wenn Sie richtig viel Zeit und Mühe in die Konfiguration eines Programms investieren, und schon das nächste Update ihre Konfigurationsdateien platt macht. Debian löst dieses Problem, indem die Konfigurationsdateien markiert werden und der Administrator beim nächsten Paket-Upgrade gefragt wird, ob er seine Konfiguration behalten will oder nicht. Zu markierende Konfigurationsdateien können Sie in die Datei `conffiles' eintragen, pro Zeile ein Dateiname mit dem vollständigen Pfad der Konfigurationsdatei (normalerweise in `/etc/'). Gentoo hat eine Konfigurationsdatei, `/etc/gentoorc', also werden Sie diesen String in die Datei `conffiles' eintragen. Wenn Ihr Programm Konfigurationsdateien nutzt, diese aber selbst zurückschreibt, ist es das Beste, diese nicht als conffiles zu kennzeichnen, weil sonst `dpkg' den Nutzer jedes Mal auffordert Änderungen zu bestätigen. Wenn Ihr Programm, das Sie paketieren möchten, verlangt, dass der Nutzer die Konfigurationsdateien ändern muss, damit es überhaupt funktioniert, sollten Sie diese auch nicht als conffiles kennzeichnen. Beispiel-Konfigurationsdateien können Sie durch `maintainer scripts' bereitstellen, siehe Abschnitt 6.12, `postinst.ex, preinst.ex, postrm.ex, prerm.ex'. Wenn Ihr Programm keine Konfigurationsdateien braucht, kann die Datei `conffiles' aus dem Verzeichnis debian/ natürlich gelöscht werden. 6.3. cron.d.ex -------------- Wenn Ihr Paket immer wiederkehrende Aufgaben erledigen muss, um ordentlich zu arbeiten, können Sie diese Datei benutzen um das einzurichten. Beachten Sie, dass dies nicht die `log-rotation' einschließt, siehe dh_installlogrotate(1) und logrotate(8). (A.d.Ü: Ein Programm, mit dem man das unbegrenzte Wachstum der Log-Dateien verhindern kann.) Wenn Sie das nicht brauchen, entfernen Sie die Datei. 6.4. dirs --------- In dieser Datei werden Verzeichnisse festgelegt, die Sie brauchen, aber von der Installationsprozedur (hier: "make install") nicht automatisch erstellt werden. Die Vorlage sieht so aus: usr/bin usr/sbin Beachten Sie, dass kein einleitender Schrägstrich dabei ist. Normalerweise würden Sie das jetzt in Folgendes ändern: usr/bin usr/man/man1 Allerdings werden diese Verzeichnisse bereits durch das Makefile erstellt, also brauchen Sie die Datei `dirs' nicht und werden sie löschen. 6.5. docs --------- Diese Datei enthält die Namen der Dokumentations-Dateien, die `dh_installdocs' für Sie ins Unterverzeichnis debian/ installieren wird. Standardmäßig schließt das alle Dateien im obersten Verzeichnis des Quellcode-Verzeichnisbaums ein, die da heißen "BUGS", "README*", "TODO" usw. Für Gentoo fügen Sie noch Weiteres hinzu: BUGS CONFIG-CHANGES CREDITS ONEWS README README.gtkrc TODO Sie können die Datei auch löschen und stattdessen die Dateinamen in die Kommandozeile von `dh_installdocs' in der Datei `rules', wie hier: dh_installdocs BUGS CONFIG-CHANGES CREDITS ONEWS README \ README.gtkrc TODO Sollten Sie keine dieser Dateien in Ihrem Paket haben, können Sie die Datei auch löschen. Aber löschen Sie nicht den Aufruf `dh_installdocs' in der Datei `rules', da dieser auch die Datei `copyright' installiert und andere Dinge tut. 6.6. emacsen-*.ex ----------------- Wenn Ihr Paket Emacs-Dateien mitbringt, die während der Installation des Pakets kompiliert werden, sollten Sie diese Datei dafür nutzen. Sie werden durch dh_installemacsen(1) im Unterverzeichnis installiert, vergessen Sie also nicht, diese Zeile in der Datei `rules' auszukommentieren, wenn Sie das benutzen. Wenn Sie das nicht benötigen, löschen Sie die Datei. 6.7. init.d.ex -------------- Wenn Ihr Paket einen Dienst enthält, der beim Hochfahren des Systems gestartet werden muss, haben Sie die anfänglichen Empfehlungen offensichtlich missachtet, stimmt's? :-) Es ist wirklich ein sehr allgemeines Grundgerüst für ein Skript, das in `/etc/init.d/' installiert werden soll, es hat reichlich Anpassungsbedarf. Es wird durch dh_installinit(1) in das Unterverzeichnis installiert. Wenn Sie das nicht benötigen, löschen Sie die Datei. 6.8. manpage.1.ex, manpage.sgml.ex ---------------------------------- Ihr Programm sollte eine Manpage haben. Hat es keine, dann können Sie die erstellte Vorlage umbenennen und mit dem eigenen Text füllen. Manual-Seiten werden üblicherweise in nroff(1) geschrieben. Das Beispiel `manpage.1.ex' ist auch in nroff geschrieben. In den Manpages von man(7) finden Sie weitere Hinweise zur Erstellung von Man-Seiten. Wenn Sie es andererseits bevorzugen in SGML anstatt nroff zu schreiben, können Sie die Datei `manpage.sgml.ex' benutzen. Dann müssen Sie Folgendes tun: * Installieren Sie das Paket `docbook-to-man', * fügen Sie `docbook-to-man' der Zeile `Build-Depends' in der Datei `control' hinzu und * aktivieren Sie den Aufruf docbook-to-man in der Rule `build' der Datei `rules'. Vergessen Sie nicht, die Datei in `gentoo.sgml' umzubenennen! Die endgültige Manpage-Datei sollte den Namen des Programms, das dokumentiert wird, erhalten. Deshalb ändern Sie den Namen von "manpage" nach "gentoo". Die Datei muss auch eine ".1" als erste Endung erhalten, d.h. es handelt sich um eine Manpage für ein Nutzer-Kommando. Stellen Sie sicher, dass Sie die richtige Kategorie gewählt haben. Hier ist eine kurze Liste der Kategorien: Sektion | Beschreibung | Anmerkungen 1 Benutzerkommandos Ausführbare Programme oder Skripte 2 Systemaufrufe Kernelfunktionen 3 Bibliotheksaufrufe Funktionen in System-Bibliotheken 4 Spezielle Dateien gewöhnlich in /dev 5 Dateiformate und Konventionen z.B. das Format von /etc/passwd 6 Spiele und ähnliche Programme 7 Makropakete und Konventionen z.B. man(7), groff(7) 8 Systemadministrations- befehle in der Regel nur für root 9 Kernelroutinen [Nicht Standard] Also bekommt unsere Manpage den Dateinamen `gentoo.1'. Im gentoo-Archiv gab es keine Manpage `gentoo.1', also hat der Autor eine geschrieben, mit Hilfe der Informationen aus dem Beispiel und aus der Dokumentation des Upstreams. 6.9. menu.ex ------------ Benutzer von "X Window System" haben normalerweise einen Fenstermanager mit konfigurierbaren Menüs, aus dem die Programme gestartet werden. Wenn Sie das Debian-Paket `menu' installiert haben, wird eine Reihe Menü-Einträge für die installierten Programme automatisch hinzugefügt. Standardmäßig erstellt `dh_make' die Datei `menu' so: ?package(gentoo):needs=X11|text|vc|wm section=Apps/see-menu-manual\ title="gentoo" command="/usr/bin/gentoo" Das erste Feld nach dem Doppelpunkt ist "needs" und bestimmt, welche Art der Benutzerschnittstelle das Programm braucht. Lassen Sie nur die zutreffende Option stehen, z.B. "text" oder "X11". Das nächste ist "section", in welchem Menü und Untermenü der Eintrag später erscheinen soll. Die aktuelle Liste der Sektionen ist in: `/usr/share/doc/debian-policy/menu-policy.html/ch2.html#s2.1' zu finden. Das Feld "title" enthält den Namen des Programms. Der kann mit Großbuchstaben beginnen, sollte aber kurz gehalten werden. Zuletzt das Feld "command", das den Kommandoaufruf zum Starten des Programms enthält. Den Menü-Eintrag verändern Sie also zum folgenden: ?package(gentoo): needs=X11 section=Apps/Tools title="Gentoo"\ command="gentoo" Sie können noch weiter Felder wie "longtitle", "icon", "hints" usw. hinzufügen. Siehe menufile(5), update-menus(1) und `/usr/share/doc/debian-policy/menu-policy.html/' für mehr Infos. 6.10. watch.ex -------------- Mit dieser Datei können Sie uscan(1)- und uupdate(1)-Programme (aus dem Paket `devscripts') konfigurieren. Diese sind nützlich, um die Seite zu überwachen, von der Sie die Original-Quellen bezogen haben. Folgendes könnten Sie da eintragen: # watch control file for uscan # Site Directory Pattern Version Script ftp.obsession.se /gentoo gentoo-(.*)\.tar\.gz debian uupdate Hinweis: Wechseln Sie, wenn Sie die Datei einmal erstellt haben, mit einer bestehenden Internetverbindung in das Arbeitsverzeichnis und probieren Sie, "uscan" auszuführen. Und RTFM. :) 6.11. ex.package.doc-base ------------------------- Hat Ihr Programm noch andere Dokumentationen, nicht nur Man- und Info-Seiten, so sollten Sie die Datei ``doc-base'' benutzen, um diese zu registrieren, damit der Benutzer sie mit Programmen wie dhelp(1), dwww(1) oder doccentral(1) finden kann. Das schließt normalerweise HTML-, PS- und PDF-Dateien ein, die sich in `/usr/share/doc/packagename/' befinden. So könnte Gentoo's Datei `gentoo.doc-base' dann aussehen: Document: gentoo Title: Gentoo Manual Author: Emil Brink Abstract: This manual describes what Gentoo is, and how it can be used. Section: Apps/Tools Format: HTML Index: /usr/share/doc/gentoo/html/index.html Files: /usr/share/doc/gentoo/html/*.html Informationen über das Format dieser Datei finden Sie in install-docs(8) und der Anleitung von `doc-base' in `/usr/share/doc/doc-base/doc-base.html/'. 6.12. postinst.ex, preinst.ex, postrm.ex, prerm.ex -------------------------------------------------- Diese Dateien werden Maintainer-Skripte genannt. Das sind Skripte die im Kontroll-Bereich des Pakets liegen und von `dpkg' ausgeführt werden, und zwar, wenn Ihr Paket installiert, aktualisiert oder entfernt wird. Vorerst sollten Sie aber von den Maintainer-Skripten die Finger lassen, weil die manuelle Bearbeitung schnell kompliziert werden kann. Mehr Informationen finden Sie in der Policy, Kapitel 6, und werfen Sie einen Blick auf die Beispiele von `dh_make'. ------------------------------------------------------------------------------- 7. "Bau" des Pakets ------------------- Nun sollten Sie soweit sein, das Paket zu "bauen". 7.1. Kompletter Neubau ---------------------- Wechseln Sie nun in das Verzeichnis des Programms und führen Sie das folgende Kommando aus: dpkg-buildpackage -rfakeroot Das wird alles für Sie erledigen. In Einzelnen: * Aufräumen des Quell-Verzeichnisbaumes (debian/rules clean), mittels `fakeroot', * Bauen des Quell-Pakets (dpkg-source -b), * Bauen des Programms (debian/rules build,) * Bauen des Binär-Pakets (debian/rules binary), mittels `fakeroot', * signieren der Quell-Datei `*.dsc', mittels `gnupg', * erstellen und signieren der Upload-Datei `.changes', mittels `dpkg-genchanges' und `gnupg'. Sie müssen nur zweimal Ihr Passwort für den GPG-Schlüssel eingeben. Nachdem das erledigt ist, werden Sie folgende Dateien im darüberliegenden Verzeichnis (`~/gentoo/') vorfinden: * _gentoo_0.9.12.orig.tar.gz_ Dies ist der ursprüngliche Quellcode-Tarball, lediglich umbenannt, um dem Debian-Standard zu genügen. * _gentoo_0.9.12-1.dsc_ Dies ist eine Zusammenfassung des Inhalts des Quellcode-Pakets. Sie wird aus Ihrer Datei `control' generiert und für das Entpacken des Quellcodes mittels dpkg-source(1) benötigt. Diese Datei ist mit GPG signiert, somit können sich die Leute vergewissern, dass sie von ihnen kommt. * _gentoo_0.9.12-1.diff.gz_ Diese komprimierte Datei enthält alle Zusätze und Änderungen, die Sie mit dem ursprünglichen Quellcode gemacht haben, im Format, das als "unified diff" bekannt ist. Die Datei wird erstellt und benutzt von dpkg-source(1). Wenn Sie den originalen Tarball nicht `paketname_version.orig.tar.gz' genannt haben, wird `dpkg-source' bei der Generierung der Datei `*.diff.gz' scheitern! Wenn jemand Ihr Paket von Grund auf neu bauen will, kann er die drei o.g. Dateien dazu verwenden. Das Verfahren ist trivial: kopieren Sie einfach die drei Dateien in ein Verzeichnis und starten Sie `dpkg-source -x gentoo_0.9.12-1.dsc`. * _gentoo_0.9.12-1_i386.deb_ Das ist Ihr fertiges Binär-Paket. Sie können es mit `dpkg' installieren und wieder entfernen wie jedes andere Paket auch. * _gentoo_0.9.12-1_i386.changes_ Diese Datei beschreibt die Änderungen in dieser Paket-Revision. Die Verwaltungsprogramme für Debians FTP-Archive benötigen diese Datei zur Installation der Binär- und Quellcode-Pakete ins FTP-Archiv. Sie wird zum Teil aus den Dateien `changelog' und `*.dsc' generiert. Diese Datei ist GPG-signiert, so dass man sicher sein kann, dass sie wirklich von Ihnen ist. Wenn Sie weiter an dem Paket arbeiten, wird sich das Verhalten ändern und Sie werden neue Funktionen hinzufügen. Leute, die Ihr Paket herunterladen, können sich die Datei ansehen und feststellen, was sich geändert hat. Das Debian-Archiv-Verwaltungsprogramm wird den Inhalt dieser Datei auch an die debian-devel-changes Mailingliste schicken. Die langen Zahlenreihen in den Dateien `*.dsc' und `.changes' sind MD5-Prüfsummen dieser Dateien. Jemand, der Ihr Paket herunterlädt, kann die enthaltenen Dateien mit md5sum(1) testen und wenn die Zahlen nicht übereinstimmen, weiß er, die geprüfte Datei ist beschädigt oder manipuliert. 7.2. Schneller Neubau --------------------- Bei einem großen Paket wollen Sie bestimmt nicht alles nach jeder kleiner Änderung in `debian/rules' neu kompilieren. Für Testzwecke können Sie ein .deb erstellen, ohne alle Schritte durchzumachen, z.B. so: fakeroot debian/rules binary Wenn Sie mit Ihren Anpassungen fertig, vergessen Sie nicht, nach der kompletten Prozedur das Paket endgültig zu bauen. Sie werden Pakete, die auf diese Weise gebaut sind, nicht korrekt hochladen können. 7.3. Das Kommando `debuild' --------------------------- Sie können das Paketbauen in Zukunft mit dem Kommando `debuild' automatisieren. (siehe debuild(1)) Das Kommando `debuild' kann in den Dateien `/etc/devscripts.conf' oder `~/.devscripts' benutzerbezogen angepasst werden. Die folgenden Einträge sind mindestens empfohlen: DEBSIGN_KEYID="Ihre_GPG_Schlüssel_ID" DEBUILD_DPKG_BUILDPACKAGE_OPTS="-i -ICVS -I.svn" Damit werden Ihre gebauten Pakete immer mit Ihrem GPG-Schlüssel signiert und es werden unerwünschte Dateien und Verzeichnisse im Paket verhindert. (Das ist auch für Sponsoren geeignet.) Beispielsweise ist das Säubern des Quellverzeichnisses und Neubauen des Pakets als Benutzer so einfach, wie: debuild clean debuild 7.4. Das `dpatch'-System ------------------------ Die einfach zu nutzenden Kommandos `dh_make' und `dpkg-buildpackage' erstellen eine große Datei `*.diff.gz', die alle Dateien für die Paketbetreuung in `debian/' und Patch-Dateien für den Quellcode enthält. So ein Paket ist sehr mühselig zu kontrollieren und jede Änderung des Quellcodes ist später schwer zu verstehen. Das ist nicht so schön. [1] Verschiedene Möglichkeiten der Betreuung von Patch-Sets wurden vorgeschlagen und werden in Debian verwendet. Das `dpatch'-System ist eines der einfachsten. Andere sind dbs, cdbs, etc. Ein Paket, das ordentlich mit dem `dpatch'-System erstellt wurde, enthält die Änderungen des Quellcodes klar dokumentiert als Patch-Set-Dateien in `debian/patches/' und der Quellcode außerhalb des Verzeichnisses `debian/' bleibt unberührt. Wenn Sie Ihren Sponsor bitten, Ihr Paket hochzuladen, ist diese klare Trennung und Dokumentation Ihrer Änderungen für die zügige Überprüfung des Pakets durch Ihren Sponsor sehr wichtig. Der Umgang mit `dpatch' wird in dpatch(1) erklärt. Wenn Ihnen jemand (einschließlich Ihnen selbst) später einen Patch für den Quellcode zur Verfügung stellt, ist die Anpassung des Pakets mit `dpatch' recht einfach: * Patch anpassen, zu einem "-p1"-Patch zum Quellcode machen. * Kopfzeilen mit dem Kommando `dpatch patch-template' hinzufügen. * Im Verzeichnis `debian/patches' ablegen. * Den Dateinamen in die `debian/patches/00list' schreiben. `dpatch' bietet auch die Möglichkeit, Patches durch das CPP-Macro architekturabhängig zu machen. [1] Wenn Sie noch kein Debian-Entwickler sind und Ihren Sponsor bitten, Ihr Paket nach einer Überprüfung hochzuladen, sollten Sie Ihr Paket so einfach wie möglich für ihn überprüfbar machen. 7.5. Einbeziehen von `*.orig.tar.gz' beim Hochladen --------------------------------------------------- Wenn Sie das Paket zum ersten Mal in das Archiv hochladen, müssen Sie die Original-Quellen `*.orig.tar.gz' einbeziehen. Wenn die Paketversion nicht eine `-0' oder `-1' als Debian-Revisionsnummer hat, müssen Sie dem Kommando `dpkg-buildpackage' die Option "`-sa'" mitgeben. Dem gegenüber erzwingt die Option "`-sd'" den Ausschluss der Original-Quellen `*.orig.tar.gz'. ------------------------------------------------------------------------------- 8. Überprüfung des Pakets auf Fehler ------------------------------------ 8.1. Die Pakete `lintian' ------------------------- Lassen Sie lintian(1) auf ihre Datei `*.changes' los; diese Programme finden viele Fehler, die beim Paketerstellen häufig gemacht werden. Die Aufrufe sind folgende: lintian -i gentoo_0.9.12-1_i386.changes Den Dateinamen ersetzen Sie durch den Namen der Datei `*.changes' Ihres Pakets. Erscheinen bei der Überprüfung einige Fehler, (mit E: anfangende Zeilen), lesen Sie die Erklärung (die N:-Zeilen), korrigieren Sie die Fehler und erstellen Sie das Paket neu, wie in Abschnitt 7.1, `Kompletter Neubau' beschrieben wurde. Erscheinen nur Zeilen mit W: am Anfang, dann sind es Warnungen. Sie sollten die Ursachen berichtigen oder sich davon überzeugen, dass die Warnungen unbegründet sind (und `lintian' zwingen, das zu akzeptieren; siehe die Dokumentation für Details). Noch ein Tipp: Sie können `dpkg-buildpackage' und `lintian' auf einmal ausführen, mit dem Befehl debuild(1). 8.2. Das Programm `mc' ---------------------- Sie können den Inhalt eines `.deb'-Pakets mit dem Kommando dpkg-deb(1) auspacken. Sie können den Inhalt eines Debian-Pakets mit dem Kommando debc(1) anzeigen. Ein Dateimanager wie mc(1) kann die Arbeit vereinfachen, indem er Ihnen nicht nur den Inhalt eines `.deb'-Pakets anzeigt, sondern auch die Dateien `*.diff.gz' und `*.tar.gz'. Halten Sie im Binär- und Quell-Paket Ausschau nach unnötigen oder leeren Dateien. Meistens wurde dieser Müll nicht richtig entfernt; passen Sie die Datei `rules' an, das zu tun. Tipps: * ``zgrep ^+++ ../gentoo_0.9.12-1.diff.gz'' zeigt Ihnen eine Liste Ihre Änderungen/Hinzufügungen zu den Quellcode-Dateien * ``dpkg-deb -c gentoo_0.9.12-1_i386.deb'' oder ``debc gentoo_0.9.12-1_i386.changes'' listet die Dateien des Binär-Pakets auf. 8.3. Das Kommando `debdiff' --------------------------- Sie können mit dem Kommando debdiff(1) die Dateilisten in zwei Binär-Paketen vergleichen. Damit können Sie überprüfen, dass keine Dateien unabsichtlich verschoben oder gelöscht wurden und keine anderen versehentlichen Veränderungen bei der Aktualisierung des Pakets eingetreten sind. Mit dem Kommando ``debdiff old-package.change new-package.change'' können Sie einfach mehrere `.deb'-Pakete überprüfen. 8.4. Das Kommando `interdiff' ----------------------------- Sie können mit dem Kommando interdiff(1) zwei Dateien `*.diff.gz' vergleichen. Damit können Sie überprüfen, dass keine versehentlichen Veränderungen am Quellcode bei der Aktualisierung des Pakets durch den Paket-Betreuer eingetreten sind. Rufen Sie ``interdiff -z old-package.diff.gz new-package.diff.gz'' auf. 8.5. Das Kommando `debi' ------------------------ Installieren Sie das Paket nun selbst, z.B. mit dem Kommando debi(1) als root. Versuchen Sie jetzt, das Paket auf anderen Rechnern zu installieren und das Programm laufen zu lassen, achten Sie dabei auf Warnungen und Fehlermeldungen während der Installation und Ausführung. 8.6. Das Paket `pbuilder' ------------------------- Das Paket `pbuilder' ist sehr gut geeignet, die Build-Abhängigkeiten in einer sauberen Build-Umgebung (chroot) zu überprüfen. Das stellt ein problemloses Bauen des Pakets aus den Quellen auf den Auto-Buildern für verschiedene Architekturen sicher und verhindert einen schwerwiegenden FTBFS-Bug, der immer release-kritisch (RC) ist. Siehe http://buildd.debian.org/ für mehr Informationen über die Debian-Auto-Builder. Am einfachsten nutzen Sie das Paket `pbuilder' durch direkten Aufruf des Kommandos `pbuilder' als Benutzer root. Führen Sie beispielsweise folgende Kommandos in dem Verzeichnis aus, das die Dateien `*.orig.tar.gz', `*.diff.gz' und `*.dsc' enthält, um ein Paket zu bauen. root # pbuilder create # if second time, pbuilder update root # pbuilder build foo.dsc Das neu gebaute Paket befindet sich unter `/var/cache/pbuilder/result/' und gehört root. Das Kommando `pdebuild' ermöglicht Ihnen, das Paket `pbuilder' als normaler Benutzer zu nutzen. Im Wurzelverzeichnis des Quellcodes, die Datei `*.orig.tar.gz' liegt im übergeordneten Verzeichnis, führen Sie folgende Kommandos aus: $ sudo pbuilder create # if second time, sudo pbuilder update $ pdebuild Das neu gebaute Paket befindet sich unter `/var/cache/pbuilder/result/' und gehört nicht root. [1] Wenn Sie in eine zusätzliche APT-Quelle hinzufügen wollen, die vom Paket `pbuilder' benutzt werden soll, setzen Sie `OTHERMIRROR' in der Datei `~/.pbuilderrc' oder `/etc/pbuilderrc' und starten (für Sarge): $ sudo pbuilder update --distribution sarge --override-config Die Option `--override-config' muss mitgegeben werden, um die APT-Quelle in der chroot-Umgebung zu aktualisieren. Siehe http://www.netfort.gr.jp/~dancer/software/pbuilder.html, pdebuild(1), pbuilderrc(5) und pbuilder(8). [1] Sie sollten eventuell Ihr System anpassen, indem Sie das Verzeichnis `/var/cache/pbuilder/result/' für die Benutzer schreibbar machen und in der Datei `~/.pbuilderrc' oder `/etc/pbuilderrc' Folgendes hinzufügen: AUTO_DEBSIGN=yes Damit können Sie die erzeugten Pakete mit Ihrem geheimen GPG-Schlüssel unter `~/.gnupg/' signieren. Da sich das Paket `pbuilder' in ständiger Entwicklung befindet, sollten Sie die aktuellen Einstellmöglichkeiten in der letzten offiziellen Dokumentation nachschlagen. ------------------------------------------------------------------------------- 9. Hochladen des Pakets ----------------------- Nun, nachdem Sie das Paket ausreichend getestet haben, können Sie sich als neuer Debian-Entwickler bewerben, der sog. "Debian new maintainer application process", näher beschrieben unter http://www.debian.org/devel/join/newmaint, beginnt. 9.1. Hochladen in das Debian-Archiv ----------------------------------- Wenn Sie dann offizieller Entwickler geworden sind, werden Sie das Paket in das Debian-Archiv hochladen wollen. Sie können das per Hand erledigen, aber es ist einfacher, das mit den bereitgestellten Werkzeugen wie dupload(1) oder dput(1) zu automatisieren. Hier wird die Handhabung von `dupload' beschrieben. Zunächst müssen Sie `dupload''s Konfigurationsdatei erstellen. Sie können entweder die systemweite Datei `/etc/dupload.conf' verändern oder Sie nehmen in Ihrer eigenen Datei ``~/.dupload.conf'' die wenigen Änderungen, die Sie benötigen, vor. Schreiben Sie etwas wie folgendes dort hinein: package config; $default_host = "anonymous-ftp-master"; $cfg{'anonymous-ftp-master'} = { fqdn => "ftp-master.debian.org", method => "ftp", incoming => "/pub/UploadQueue/", # files pass on to dinstall on ftp-master which sends emails itself dinstall_runs => 1, }; 1; Natürlich ersetzen Sie die Angaben durch Ihre eigenen und lesen die Manpage für dupload.conf(5), um die einzelnen Optionen zu verstehen. Die schwierigste Option ist <$default_host> -- sie legt fest, welche Warteschlange beim Hochladen normalerweise benutzt wird. Die bevorzugte Queue ist "anonymous-ftp-master", aber es ist möglich, dass Sie eine andere, schnellere nutzen wollen. Mehr Informationen über die "Upload Queues" finden Sie in der Entwickler-Referenz, Sektion "Uploading a package", in `/usr/share/doc/developers-reference/ch-pkgs.en.html#s-upload' Bauen Sie eine Verbindung zu Ihrem Internet-Provider auf, und führen Sie dieses Kommando aus: dupload gentoo_0.9.12-1_i386.changes `dupload' vergleicht die MD5-Prüfsummen mit denen aus der Datei ``*.changes'' und weist Sie ggf. an, das Paket neu zu "bauen", wie unter es Abschnitt 7.1, `Kompletter Neubau' bereits beschrieben wurde. Wenn Sie ein Problem beim Hochladen auf ftp://ftp-master.debian.org/pub/UploadQueue/ feststellen, können Sie das selbst beheben, indem Sie mit dem Programm `ftp' eine GPG-signierte Datei `*.commands' nach ftp://ftp-master.debian.org/pub/UploadQueue/ kopieren. [1] Beispiel `hello.commands': -----BEGIN PGP SIGNED MESSAGE----- Uploader: Roman Hodek Commands: rm hello_1.0-1_i386.deb mv hello_1.0-1.dsx hello_1.0-1.dsc -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia iQCVAwUBNFiQSXVhJ0HiWnvJAQG58AP+IDJVeSWmDvzMUphScg1EK0mvChgnuD7h BRiVQubXkB2DphLJW5UUSRnjw1iuFcYwH/lFpNpl7XP95LkLX3iFza9qItw4k2/q tvylZkmIA9jxCyv/YB6zZCbHmbvUnL473eLRoxlnYZd3JFaCZMJ86B0Ph4GFNPAf Z4jxNrgh7Bc= =pH94 -----END PGP SIGNATURE----- [1] Siehe ftp://ftp-master.debian.org/pub/UploadQueue/README. Sie können auch das Kommando `dcut' aus dem Paket `dput' benutzen. 9.2. Hochladen in ein privates Archiv ------------------------------------- Wenn Sie ein privates Archiv unter `URL="http://people.debian.org/~"' erstellen wollen, können Sie das als Entwickler durch den einfachen Aufruf von `dupload -t '. Die sollten der Datei `/etc/dupload.conf' folgende Zeilen hinzufügen: # Entwickler-Zugang $cfg{''} = { fqdn => "people.debian.org", method => "scpb", incoming => "/home//public_html/package/", # I do not need to announce dinstall_runs => 1, }; $cfg{''}{preupload}{'changes'} = " echo 'mkdir -p public_html/package' | ssh people.debian.org \ 2>/dev/null; echo 'Package directory created!'"; $cfg{''}{postupload}{'changes'} = " echo 'cd public_html/package ; dpkg-scanpackages . /dev/null >Packages || true ; dpkg-scansources . /dev/null >Sources || true ; gzip -c Packages >Packages.gz ; gzip -c Sources >Sources.gz ' | ssh people.debian.org \ 2>/dev/null; echo 'Package archive created!'"; Dabei wird das APT-Archiv durch einen entfernten "quick-and-dirty"-Shell-Aufruf über SSH realisiert. Die von den Programmen `dpkg-scanpackages' und `dpkg-scansources' benötigten Dateien `override' werden durch `/dev/null' ersetzt. Auf diese Weise können Sie auch ohne Debian-Entwickler zu sein, Ihre Pakete auf Ihrer privaten Internetseite bereitstellen. Sie können aber auch `apt-ftparchive' oder andere Skripte benutzen, um das APT-Archiv zu erstellen. ------------------------------------------------------------------------------- 10. Weiterentwicklung des Pakets -------------------------------- 10.1. Eine neue Debian Revision ------------------------------- Angenommen, es wurde ein Bug-Report (#54321) erstellt, und er beschreibt ein Problem, das Sie lösen können. Um eine neue Revision zu erstellen haben Sie folgendes zu tun: * Lösen Sie das Problem im Quellcode (wohl selbstverständlich). * Machen Sie einen neuen Revisions-Eintrag an oberster Stelle in der Datei `changelog', z.B. mit ``dch -i'`, oder explizit mit ``dch -v -'` Tipp: Wie bekommen Sie das Datum ins richtige Format? Nehmen Sie `822-date' oder `date' mit der Option "-R". * Fügen Sie eine kleine Beschreibung des Bugs und der Lösung dem Eintrag hinzu, gefolgt von: "Closes: #54321". Auf diese Weise wird der Bug-Report von der Verwaltungssoftware "automagisch" geschlossen, sobald das Paket ins Debian-Archiv übernommen wurde. * Wiederholen Sie die Schritte aus Abschnitt 7.1, `Kompletter Neubau', Kapitel 8, `Überprüfung des Pakets auf Fehler', und Kapitel 9, `Hochladen des Pakets'. Der einzige Unterschied ist jetzt nur, dass der Original-Quellcode nicht mehr hochgeladen wird, da das Tar-Archiv nicht mehr geändert wurde und die alte Version bereits auf dem Server liegt. 10.2. Ein neues Upstream-Release (einfach) ------------------------------------------ Dies ist eine andere, etwas kompliziertere Situation - eine neue Upstream-Version wurde freigegeben und Sie wollen diese natürlich gleich übernehmen. Sie können nun folgendes tun: * Den neuen Quellcode-Tarball herunterladen (z.B. das Archiv ``gentoo-0.9.13.tar.gz''), in das Verzeichnis über dem alten Quellcode-Verzeichnis (z.B. ``~/gentoo/'') ablegen. * Das alte Quellcode-Verzeichnis (gentoo-0.9.12) betreten und folgendes ausführen: uupdate -u gentoo-0.9.13.tar.gz Natürlich ersetzen Sie den Dateinamen durch den Namen des neuen Source-Tarballs Ihres Programms. uupdate(1) wird es dann richtig umbenennen und versuchen, alle Änderungen aus Ihrer vorherigen Datei ``*.diff.gz'' in die neue Version zu übernehmen. Anschließend wird die Datei ``debian/changelog'' aktualisiert. * Wechseln Sie in das neue Verzeichnis ``../gentoo-0.9.13'', Ihr neues Quellcode-Arbeitsverzeichnis, und wiederholen Sie die Schritte aus Abschnitt 7.1, `Kompletter Neubau', Kapitel 8, `Überprüfung des Pakets auf Fehler' und Kapitel 9, `Hochladen des Pakets'. Übrigens können Sie, vorausgesetzt Sie haben `debian/watch' wie in Abschnitt 6.10, `watch.ex' aufgesetzt, durch Ausführung von uscan(1) "automagisch" nach aktuellem Quellcode suchen, ihn herunterladen und `uupdate' durchführen. 10.3. Ein neues Upstream-Release (in Wirklichkeit) -------------------------------------------------- Wenn Sie Pakete für das Debian-Archiv vorbereiten, müssen Sie die erstellten Paket eingehend prüfen. Es folgt ein realistischeres Beispiel für dieses Vorgehen. 1. Überprüfen der Änderungen im Programm-Quellcode * Lesen Sie die Dateien `changelog', `NEWS' und andere Dokumentationen der neuen Version des Upstream-Autors. * Führen Sie ``diff -urN'' zwischen dem alten und neuen Programm-Quellcode aus, um ein Gefühl für den Umfang der Änderungen zu bekommen, woran aktiv gearbeitet wurde (wodurch neue Fehler auftreten könnten) und halten Sie Ausschau nach allem, was verdächtig erscheint. 2. Bringen Sie das alte Debian-Paket auf die neue Version. * Packen Sie den Quell-Tarball aus, benennen Sie das Wurzelverzeichnis des Quellcodes in `-/' um und wechseln Sie in dieses Verzeichnis. * Kopieren Sie den Quell-Tarball in das übergeordnete Verzeichnis und benennen Sie ihn in `_.orig.tar.gz' um. * Wenden Sie auf den Quellcode der neuen Version die gleichen Änderungen an, wie bei der alten. Möglich ist das durch: * das Kommando ``zcat _.diff.gz | patch -p1'', * das Kommando ``uupdate'', * das Kommando ``svn merge'', wenn Sie den Quellcode in einem Subversion-Repository verwalten oder * einfaches Kopieren des Verzeichnisses `debian/' aus dem alten Paketverzeichnis, wenn es mit `dpatch' erstellt wurde. * Behalten Sie die alten Changelog-Einträge (sollte klar sein, aber es kam schon vor ...) * Die neue Paketversion besteht aus der Upstream-Release-Version, erweitert um eine `-1' als Debian-Revisionsnummer, z.B. ``0.9.13-1''. * Fügen Sie einen Changelog-Eintrag mit "New upstream release" für diese neue Version oben in die Datei `debian/changelog' ein, z.B.: mit dem Aufruf ``dch -v 0.9.13-1''. * Beschreiben Sie kurz die Änderungen _im_ neuen Upstream-Release, die gemeldete Fehler beheben und schließen Sie diese Fehler im Changelog. * Beschreiben Sie kurz die Änderungen _am_ neuen Upstream-Release, die Sie als Betreuer vorgenommen haben und die gemeldete Fehler beheben; schließen Sie diese Fehler im Changelog. * Wenn das Patchen/Zusammenführen nicht problemlos abläuft, untersuchen Sie die Fehler, um zu sehen, was schief geht (Hinweise geben die Dateien `*.rej'). Meistens stellt sich heraus, dass ein Patch, den Sie auf den Quellcode anwenden wollen, schon durch den Upstream-Autor in den Quellcode integriert wurde und der Patch nicht mehr gebraucht wird. * Die Aktualisierung des Pakets beim Benutzer sollte still und unauffällig ablaufen (bestehende Benutzer sollten von der Aktualisierung nichts mitbekommen, außer der Feststellung, dass alte Fehler behoben wurden oder vielleicht neue Funktionen vorhanden sind). [1] * Wenn Sie aus irgendeinem Grund gelöschte debhelper-Template-Dateien wieder haben wollen, können Sie `dh_make' mit der Option `-o' nocheinmal im schon "debianisierten" Verzeichnis aufrufen und dann entsprechend ändern. * Vorhandene Änderungen für Debian müssen nochmals überprüft werden; entfernen Sie Sachen, die der Upstream-Autor schon eingebaut hat (in welcher Form auch immer) und behalten Sie Sachen, die noch nicht eingebaut sind, außer es gibt zwingende Gründe dagegen. * Wenn Sie Änderungen beim Bauen des Pakets vornehmen (hoffentlich haben Sie es gleich am Anfang gemerkt und die Dateien `debian/rules' und `debian/control' für die Build-Abhängigkeiten wenn nötig angepasst. 3. Bauen Sie das neue Paket, wie in Abschnitt 7.3, `Das Kommando `debuild'' oder Abschnitt 8.6, `Das Paket `pbuilder'' beschrieben. Die Nutzung von `pbuilder' ist wünschenswert. 4. Überprüfen, dass neue Pakete richtig gebaut werden. * Verfahren Sie wie in Kapitel 8, `Überprüfung des Pakets auf Fehler'. * Weiter mit Abschnitt 10.6, `Überprüfen des Upgrades'. * Überprüfen Sie erneut, ob Fehler behoben wurden, die im Debian Bug Tracking System (BTS) (http://www.debian.org/Bugs/) noch offen sind. * Überprüfen Sie den Inhalt der Datei `*.changes', damit Sie zur richtigen Distribution hochladen, die zutreffenden Fehlerbehebungen im Feld `Closes:' aufgelistet sind, die Felder `Maintainer:' und `Changed-By:' übereinstimmen, die Dateien GPG-signiert sind etc. 5. Wenn Sie während der Arbeit an dem Paket irgendetwas an der Paketierung ändern, gehen Sie zu Punkt 2 bis es passt. 6. Wenn Sie einen Sponsor hochladen lassen, weisen Sie auf alle speziellen Optionen hin, die beim Bauen des Pakets angegeben werden müssen (z.B. '`dpkg-buildpackage -sa -v ...'') hin und informieren Sie Ihren Sponsor darüber, damit er oder sie das Paket richtig baut. 7. Wenn Sie selbst hochladen, machen Sie mit Kapitel 9, `Hochladen des Pakets' weiter. [1] Bitte sorgen Sie dafür, dass Ihr Paket durch wohldurchdachtes `postinst' etc. die Konfigurationsdateien ordentlich aktualisiert, damit _nichts_ geschieht, was der Benutzer nicht will! Das sind die Verbesserungen, die erklären, _warum_ sich Leute für Debian entscheiden. Wenn es nötig ist, die Aktualisierung auffällig ablaufen zu lassen (z.B. Konfigurationsdateien sind in verschiedenen Home-Verzeichnissen mit völlig unterschiedlicher Struktur verstreut), sollten Sie als letzte Möglichkeit das Paket in einen sicheren Standardmodus bringen (z.B. den Dienst abschalten) und eine ordentliche Dokumentation gemäß der Policy (`README.Debian' und `NEWS.Debian') bereitstellen. Aber nicht den Admin mit einer debconf-Meldung belästigen. 10.4. Die Datei `*.orig.tar.gz' ------------------------------- Wenn Sie versuchen, ein Paket nur aus dem neuen entpackten Quellcode mit dem Verzeichnis `debian/' und ohne die Datei `*.orig.tar.gz' im übergeordneten Verzeichnis zu bauen, werden Sie unabsichtlich ein Nativ-Quellpaket erstellen, das keine Datei `*.diff.gz' enthält. Diese Art von Paketen sollte nur für Debian-spezifische Pakete verwendet werden, die für andere Distributionen nicht nützlich sind. [1] Um kein Nativ-Quellpaket zu erstellen, sondern eins, das die Dateien `*.orig.tar.gz' und `*.diff.gz' enthält, müssen Sie den Quellcode-Tarball selbst in das übergeordnete Verzeichnis kopieren und seinen Namen in `_.orig.tar.gz' ändern, wie es das Kommando `dh_make' in Abschnitt 3.4, `Die erste "Debianisierung"' macht. [1] Einige Leute lehnen das sogar für Debian-spezifische Pakete ab und finden es besser, den Inhalt des Verzeichnisses `debian/' in die Datei `*.diff.gz' zu packen, als in die Datei `*.orig.tar.gz'. 10.5. Das Kommando `cvs-buildpackage' und ähnliche -------------------------------------------------- Sie sollten überlegen, ein Versionskontrollsystem für die Verwaltung der Paketierungsdateien einzusetzen. Es gibt verschiedene Wrapper-Skripte, die auf die Verwendung mit den populärsten angepasst sind. * CVS * `cvs-buildpackage' * Subversion * `svn-buildpackage' * Arch (tla) * `tla-buildpackage' * `arch-buildpackage' Diese Kommandos automatisieren auch das Paketieren neuer Upstream-Releases. 10.6. Überprüfen des Upgrades ----------------------------- Wenn Sie eine neue Version Ihres Pakets gebaut haben, sollten Sie folgende Schritte ausführen, um sicher zu stellen, dass Ihr Paket problemlos aktualisiert werden kann: * Upgrade von der vorherigen Version * Downgrade zurück und dann löschen, * Installation des neuen Pakets (A.d.Ü.: ohne, dass eine vorherige Version installiert ist), * Deinstallation, erneute Installation, * dann ein "Purge". Wenn das Paket nicht triviale pre/post/inst/rm-Skripte enthält, testen Sie unbedingt deren Verhalten während einer Aktualisierung. Wenn Ihr Paket in einer früheren Version schon in Debian integriert ist, vergessen Sie nicht, auch gegen diese Version zu testen, weil viele Leute die Version aus dem letzten Debian-Release upgraden werden. ------------------------------------------------------------------------------- 11. Wo bekommt man Hilfe? ------------------------- Bevor Sie sich dazu entschließen, Ihre Frage irgendwo zu veröffentlichen, versuchen Sie es zuerst mit RTFM. Dazu gehören Dokumentationen in `/usr/share/doc/dpkg', `/usr/share/doc/debian', `/usr/share/doc/autotools-dev/README.Debian.gz', Dateien in `/usr/share/doc/package/*' und die man/info-Seiten für alle Programme, die in diesem Artikel erwähnt wurden. Siehe auch alle Informationen auf http://nm.debian.org/ und http://people.debian.org/~mpalmer/debian-mentors_FAQ.html. Wenn Sie Fragen zum Paketieren haben und in der Dokumentation keine Antworten finden, können Sie in der Debian Mentors-Mailingliste unter nachfragen. Erfahrenere Entwickler werden Ihnen gern helfen, aber Sie sollten sich zumindest die Dokumentation durchlesen, bevor Sie fragen! Mehr Informationen zu der Mailingliste finden Sie unter: http://lists.debian.org/debian-mentors/. Wenn Sie einen Bug-Report erhalten (ja, richtige Bug-Reports!), dann wissen Sie auch, dass es an der Zeit ist, sich näher mit der Fehlerdatenbank (http://www.debian.org/Bugs/) zu beschäftigen, d.h. die Doku dort zu lesen, um mit den Reports effizient umgehen zu können. Sie sollten unbedingt die "Developers' Reference", Kapitel "Handling Bugs", in `/usr/share/doc/developers-reference/ch-pkgs.en.html#s-bug-handling' lesen. Wenn Sie dann immer noch Fragen haben, dann stellen Sie diese auf der "Debian Developers"-Mailingliste über . Mehr Informationen erhalten Sie bei http://lists.debian.org/debian-devel/. Auch wenn alles richtig funktioniert hat, ist es jetzt Zeit für ein Gebet. Warum? Weil in wenigen Stunden (oder Tagen) die Benutzer aus aller Welt ihr Paket benutzen werden - und da Sie irgendwo kritische Fehler gemacht haben, werden Sie von Tausenden von verärgerten Debian-Benutzern zugemailt ... Nur ein Scherz. :-) Entspannen sie Sich und machen Sie sich auf Bug-Meldungen gefasst, da i.d.R. noch viel Arbeit zu erledigen ist, bis Ihr Paket den "Debian policies" vollständig entspricht (und noch einmal: lesen Sie in der _richtigen Dokumentation_ über Details). Viel Glück! ------------------------------------------------------------------------------- A. Beispiele ------------ Jetzt paketieren Sie den Quellcode-Tarball .tar.gz und laden alle Pakete nach `' hoch. A.1. Einfaches Beispielpaket ---------------------------- $ mkdir -p # neues leeres Verzeichnis $ cd $ tar -xvzf .tar.gz # Quellcode auspacken $ cd $ dh_make -e -f .tar.gz ... Fragen beantworten ... Quellcode anpassen ... Wenn es ein Skript-Paket ist, in der Datei debian/control "Architecture: all" eintragen. ... Die Datei ../.orig.tar.gz nicht löschen. $ debuild ... Darauf achten, dass keine Warnungen auftreten. $ cd .. $ dupload -t _i386.changes A.2. Beispielpaket mit `dpatch' und `pbuilder' ---------------------------------------------- $ mkdir -p # neues leeres Verzeichnis $ cd $ tar -xvzf .tar.gz $ cp -a $ cd $ dh_make -e -f /Pfad/von/.tar.gz ... Fragen beantworten ... Quellcode anpassen ... Erstellen Sie das Paket mit "dpkg-buildpackage -rfakeroot -us -uc" ... Quellcode anpassen bis das Paket richtig baut. ... Die Datei ../.orig.tar.gz nicht löschen. $ cd .. $ cp -a # Sicherheitskopie $ mv /debian debian $ diff -Nru \ > ... Sie könnten damit das Verzeichnis überschreiben. ... Behalten Sie unbedingt -keep zur Sicherheit. $ mkdir -p debian/patches $ dpatch patch-template \ -p "01_patchname" "patch-file description" \ < > debian/patches/01_patchname.dpatch $ cd debian/patches $ echo 01_patchname.dpatch >00list $ cd ../.. # zurück zu $ rm -rf $ editor debian/rules Die Datei `debian/rules' sieht original so aus: config.status: configure ./configure --prefix=/usr --mandir=/usr/share build: config.status ${MAKE} clean: $(testdir) $(testroot) ${MAKE} distclean rm -rf debian/imaginary-package debian/files debian/substvars Ändern Sie die Datei `debian/rules' folgendermaßen, um `dpatch' nutzen zu können: config.status: patch configure ./configure --prefix=/usr --mandir=/usr/share build: config.status ${MAKE} clean: clean-patched unpatch clean-patched: $(testdir) $(testroot) ${MAKE} distclean rm -rf debian/imaginary-package debian/files debian/substvars patch: patch-stamp patch-stamp: dpatch apply-all dpatch call-all -a=pkg-info >patch-stamp unpatch: dpatch deapply-all rm -rf patch-stamp debian/patched Jetzt sind Sie so weit, den Quellcode mit dem `dpatch'-System neu zu packen. $ tar -xvzf .orig.tar.gz $ cp -a debian/ /debian $ cd $ sudo pbuilder update $ pdebuild $ cd /var/cache/pbuilder/result/ $ dupload -t _i386.changes ------------------------------------------------------------------------------- Anleitung für zukünftige Debian-Maintainer Josip Rodin Übersetzer: Erik Schanze Übersetzer: Eduard Bloch Version 1.2.3, 18. Januar 2005.