Product SiteDocumentation Site

15.4. Paketbetreuer werden

15.4.1. Lernen Pakete zu erstellen

Creating a quality Debian package is not always a simple task. And becoming a package maintainer takes some learning, both with theory and practice in technical and legal matters. It is not a simple matter of building and installing software; rather, the bulk of the complexity comes from understanding the problems and conflicts, and more generally the interactions, with the myriad of other packages available.

15.4.1.1. Regeln

Ein Debian-Paket muss den genauen Regeln des Debian-Regelwerks entsprechen, und jeder Paketbetreuer muss sie kennen. Es ist nicht erforderlich, sie auswendig zu kennen, vielmehr muss man wissen, dass sie existieren, und jedes Mal in ihnen nachsehen, wenn eine Entscheidung mehr als eine banale Alternative darstellt. Jeder Debian-Betreuer hat Fehler gemacht, weil er eine Regel nicht kannte, jedoch ist dies kein ernstes Problem, solange der Fehler behoben wird, wenn ein Benutzer einen Fehlerbericht verfasst (was dank der erfahrenen Benutzer normalerweise recht bald geschieht). Das Standard-Version Feld in debian/control gibt die Version der Debian Richtlinie an zu dem ein Paket gehört. Die Betreuer sollten die neueste Version der Debian-Richtlinie einhalten.

15.4.1.2. Verfahren

Debian ist keine einfache Ansammlung individueller Pakete. Jedermanns Paketerstellungsarbeit ist Teil eines gemeinschaftlichen Projekts; als Debian-Entwickler muss man auch wissen, wie das Debian-Projekt als Ganzes funktioniert. Jeder Entwickler wird früher oder später mit anderen zusammenwirken. Die Debian Entwickler-Referenz (im Paket developers-reference) fasst zusammen, was jeder Entwickler wissen muss, um möglichst reibungslos mit den verschiedenen Teams innerhalb des Projekts zusammenzuarbeiten, und um die größtmöglichen Vorteile aus den verfügbaren Ressourcen zu ziehen. Dieses Dokument zählt auch eine Anzahl von Pflichten auf, deren Erfüllung von einem Entwickler erwartet wird.

15.4.1.3. Hilfsprogramme

Zahlreiche Hilfsprogramme unterstützen Paketbetreuer bei ihrer Arbeit. Dieser Abschnitt beschreibt sie kurz, aber stellt nicht alle Einzelheiten dar, da jedes von ihnen eine eigene umfassende Dokumentation besitzt.
15.4.1.3.1. devscripts
Das Paket devscripts enthält zahlreiche Programme, die einem Debian-Entwickler bei einem weiten Spektrum seiner Arbeit helfen:
  • debuild ermöglicht es, ein Paket zu erzeugen (mit dpkg-buildpackage) und dann lintian auszuführen, um seine Übereinstimmung mit dem Debian-Regelwerk zu überprüfen.
  • debclean bereinigt ein Quellpaket, nachdem ein Binärpaket erzeugt worden ist.
  • dch ermöglicht das schnelle und einfache Editieren einer debian/changelog-Datei in einem Quellpaket.
  • uscan überprüft, ob eine neue Version eines Programms vom ursprünglichen Verfasser veröffentlicht worden ist; dies erfordert eine debian/watch-Datei mit einer Beschreibung des Ortes derartiger Veröffentlichungen.
  • debi ermöglicht es, das gerade erzeugte Debian-Paket (mit dpkg -i) zu installieren, ohne dabei seinen vollständigen Namen und Pfad eingeben zu müssen.
  • In ähnlicher Weise ermöglicht es debc, den Inhalt eines vor kurzem erzeugten Pakets (mit dpkg -c) abzufragen, ohne seinen vollständigen Namen und Pfad eingeben zu müssen.
  • bts controls the bug tracking system from the command line; this program automatically generates the appropriate emails.
  • debrelease lädt ein kürzlich erzeugtes Paket auf einen entfernten Server hoch, ohne den vollständigen Namen und Pfad der dazugehörigen .changes-Datei eingeben zu müssen.
  • debsign signiert die *.dsc- und *.changes-Dateien.
  • uupdate automatisiert die Erstellung einer überarbeiteten Paketversion, wenn eine neue Ursprungsversion veröffentlicht worden ist.
All of the mentioned commands are documented in their respective manual pages. They can further be configured per user in one file: ~/.devscripts.
15.4.1.3.2. debhelper und dh-make
Debhelper is a set of scripts easing the creation of policy-compliant packages; these scripts are invoked from debian/rules. Debhelper has been widely adopted within Debian, as evidenced by the fact that it is used by the majority of official Debian packages. All the commands it contains have a dh_ prefix. Each of them is documented in a manual page. The different compatibility levels and common options are described in debhelper(7).
Das Skript dh_make (im Paket dh-make) erstellt in einem Verzeichnis, das zu Anfang die Quellen einer Software enthält, Dateien, die für die Erzeugung eines Debian-Pakets erforderlich sind. Wie aufgrund des Programmnamens vermutet werden kann, verwenden die erzeugten Dateien standardmäßig debhelper.
15.4.1.3.3. lintian
Dieses Hilfsprogramm ist eines der wichtigsten: es ist der Debian-Paket-Prüfer. Es beruht auf einer langen Reihe von Tests, die aus dem Debian-Regelwerk erstellt worden sind, und entdeckt schnell und automatisch viele Fehler, die vor der Veröffentlichung eines Pakets behoben werden können.
Dieses Programm ist nur ein Gehilfe und versteht manchmal etwas falsch (zum Beispiel ist lintian manchmal nicht aktuell, da sich das Debian-Regelwerk im Laufe der Zeit verändert). Es ist auch nicht vollständig flächendeckend: keine Lintian-Fehlermeldung zu erhalten, sollte nicht als Nachweis verstanden werden, dass das Paket perfekt ist; bestenfalls verhindert es die häufigsten Fehler.
15.4.1.3.4. piuparts
Dies ist ein weiteres wichtiges Tool; es automatisiert die Installation, Aktualisierung und Deinstallation eines Pakets (in einer isolierten Umgebung) und prüft, dass keine dieser Aktivitäten zu einem Fehler führt. Es kann helfen, fehlende Abhängigkeiten aufzudecken und es ermittelt Dateien, die fälschlicher Weise nach einer Deinstallation auf dem System verblieben sind.
15.4.1.3.5. autopkgtest
autopkgtest runs tests on binary packages, using the tests supplied in the source package in debian/tests/. Several commands allow the easy creation of chrooted or virtual test environments.
15.4.1.3.6. reprotest
reprotest erstellt den Sourcecode doppelt in unterschiedlichen Umgebungen und prüft daraufhin die mit jedem build erstellten Binärdaten auf Unterschiede. Wenn Unterschiede auftauchen, wird diffoscope (oder wenn nicht verfügbar, diff) benutzt um die Unterschiede im Detail für eine anschließende Analyse anzuzeigen.
15.4.1.3.7. dupload und dput
The dupload and dput commands allow uploading a Debian package to a (possibly remote) server. This allows developers to publish their package on the main Debian server (ftp-master.debian.org) so that it can be integrated to the archive and distributed by mirrors. These commands take a .changes file as a parameter, and deduce the other relevant files from its contents.
15.4.1.3.8. git-buildpackage and dgit
The project has been using various version control systems over the years to store packaging efforts or package source code, or allow collaborative package maintenance. In an effort to unify the systems and efforts, it was ultimately decided in 2017 to move (almost) all package sources into Git (KULTUR Git) onto a Gitlab instance called salsa.debian.org.
To make packaging using Git easier for Debian developers, tools have been developed. These allow not only to store the packaging files in Git, but also to use the Git repositories (and their history) of software projects, put patches applied to package sources into Git history, maintain software versions per distribution, etc.
One of the most famous packages is git-buildpackage. An alternative is dgit. Of course it is still possible to use neither of those.
Below is an example for a ~/.gbp.conf configuration file
[DEFAULT]
builder = sbuild -d bookworm --build-dep-resolver=aptitude -s --source-only-changes --build-failed-commands "%SBUILD_SHELL"
pristine-tar = true

[buildpackage]
sign-tags = true
keyid = XXXX
postbuild  = autopkgtest --user debci --apt-upgrade -s "$GBP_CHANGES_FILE" -- lxc --sudo autopkgtest-bookworm-amd64
export-dir = /tmp/build-area/
notify = off

[import-orig]
filter-pristine-tar = true
sign-tags = true

[pq]
drop = true
Building the package is then as easy as running gbp buildpackage in the Git tree. It will start a package build in a Debian Bookworm chroot using sbuild. When the build succeeds, the created files are checked running the autopkgtest-testsuite (if defined). All the various options are explained in gbp.conf(5) and /etc/git-buildpackage/gbp.conf.
All the tools mentioned so far have been included in the continuous integration (CI) process in the salsa.debian.org instance as well:

15.4.2. Annahmeverfahren

Ein Debian-Entwickler zu werden, ist nicht einfach eine administrative Angelegenheit. Das Verfahren besteht aus mehreren Schritten, und es ist mehr eine Initiation als ein Auswahlprozess. In jedem Fall ist es formalisiert und gut dokumentiert, so dass jeder seine Entwicklung auf der Webseite verfolgen kann, die speziell für das Annahmeverfahren für neue Entwickler vorgesehen ist.

15.4.2.1. Voraussetzungen

Von allen Kandidaten wird erwartet, dass sie wenigstens ausreichende Englischkenntnisse haben. Dies ist auf allen Ebenen erforderlich: natürlich für die anfängliche Kommunikation mit dem Prüfer, aber auch später, da Englisch für den Großteil der Dokumentation die bevorzugte Sprache ist; auch Paketbenutzer werden in Englisch kommunizieren, wenn sie Fehler melden, und werden Antworten in Englisch erwarten.
Die andere Voraussetzung bezieht sich auf die Motivation. Ein Debian-Entwickler zu werden, ist ein Prozess, der nur dann Sinn macht, wenn der Kandidat weiß, dass sein Interesse an Debian viele Monate lang anhalten wird. Der Aufnahmeprozess selbst kann mehrere Monate dauern, und Debian benötigt Entwickler langfristig; jedes Paket benötigt dauerhafte Betreuung und nicht nur einen anfänglichen Upload.

15.4.2.2. Registrierung

Er erste (wirkliche) Schritt besteht darin, einen Sponsor oder Befürworter zu finden; hierunter ist ein offizieller Entwickler zu verstehen, der bereit ist zu bestätigen, dass er davon überzeugt ist, dass die Aufnahme von X für Debian von Vorteil sein würde. Dies setzt normalerweise voraus, dass der Kandidat bereits innerhalb der Gemeinschaft aktiv gewesen und seine Arbeit anerkannt ist. Falls der Kandidat schüchtern ist und seine Arbeit nicht öffentlich angepriesen hat, kann er versuchen, einen Debian-Entwickler zu seiner Unterstützung zu bewegen, indem er ihm seine Arbeit privat zeigt.
Zur gleichen Zeit muss der Kandidat mit GnuPG ein öffentliches/privates RSA-Schlüsselpaar erzeugen, das von wenigstens zwei offiziellen Debian-Entwicklern signiert werden sollte. Die Signatur authentifiziert den im Schlüssel enthaltenen Namen. Während einer Keysigning-Party muss jeder Teilnehmer seinen Personalausweis zusammen mit seiner Schlüsselkennung vorweisen. Dieser Schritt bestätigt die offizielle Verbindung zwischen der Person und den Schlüsseln. Daher erfordert diese Signatur, dass man sich persönlich trifft. Falls Sie noch keine Debian-Entwickler bei einer öffentlichen Konferenz über freie Software getroffen haben, können Sie explizit in der Nähe wohnende Entwickler suchen, indem Sie als Ausgangspunkt die auf der folgenden Webseite stehende Liste benutzen.
Nachdem die Registrierung auf nm.debian.org von einem Unterstützer bestätigt wurde, wird dem Kandidaten ein Antragsmanager zugewiesen. Dieser Antragsmanager wird fortan das Verfahren weiterverfolgen und die verschiedenen Schritte, die dieser Prozess umfasst, bestätigen.
Die erste Überprüfung ist eine Personenkontrolle. Falls Sie bereits einen von zwei Debian-Entwicklern signierten Schlüssel besitzen, ist dieser Schritt einfach; anderenfalls wird der Antragsmanager versuchen, Ihnen bei Ihrer Suche nach in der Nähe lebenden Debian-Entwicklern zu helfen, indem er ein Treffen und eine Schlüsselsignierung organisiert.

15.4.2.3. Die Prinzipien akzeptieren

Diesen administrativen Formalitäten folgen philosophische Erwägungen. Es geht darum sicherzustellen, dass der Kandidat den Gesellschaftsvertrag und die Prinzipien Freier Software versteht und akzeptiert. Es ist nur möglich, Debian beizutreten, wenn man die Werte teilt, die die derzeitigen Entwickler eint, wie sie in den Gründungstexten bekundet sind (und zusammengefasst in Kapitel 1, Das Debian-Projekt).
Darüber hinaus wird von jedem Kandidaten, der Debian beitreten möchte, erwartet, dass er die Funktionsweise des Projekts kennt, und wie man angemessen zusammenwirkt, um Probleme zu lösen, denen er im Laufe der Zeit zweifelsohne begegnen wird. Alle diese Informationen sind im Allgemeinen in den Handbüchern dokumentiert, die für die neuen Betreuer bestimmt sind, sowie in der Debian Entwickler-Referenz. Das aufmerksame Lesen dieser Dokumente sollte genügen, um die Fragen des Prüfers beantworten zu können. Falls die Antworten nicht befriedigen, wird der Kandidat darüber informiert. Er wird dann die entsprechende Dokumentation (nochmals) lesen müssen, bevor er es erneut versucht. In den Fällen, in denen die vorhandene Dokumentation die passenden Antworten auf die Frage nicht enthält, kann der Kandidat normalerweise mit einiger praktischer Erfahrung in Debian die Antwort finden, oder vielleicht auch, indem er mit anderen Debian-Entwicklern spricht. Dieses Verfahren stellt sicher, dass Kandidaten in gewissem Umfang in Debian involviert werden, bevor sie ein vollständiger Teil von ihm werden. Es ist ein ausdrücklicher Grundsatz, dass Kandidaten, die schließlich dem Projekt beitreten, als ein weiteres Teil eines unendlich erweiterbaren Puzzles integriert werden.
Dieser Schritt wird im Jargon der am Betreuungsprozess beteiligten Entwickler gewöhnlich Philosophie & Prozeduren genannt (oder kurz P&P).

15.4.2.4. Fähigkeiten überprüfen

Jeder Antrag, ein offizieller Debian-Entwickler zu werden, muss begründet werden. Um Projektmitglied zu werden, muss man zeigen, dass dieser Status gerechtfertigt ist, und dass er dem Kandidaten seine Unterstützung für Debian erleichtert. Die häufigste Begründung besteht darin, dass der Status als Debian-Entwickler die Betreuung eines Debian-Pakets erleichtert, aber dies ist nicht die einzige. Einige Entwickler treten dem Projekt bei, um zur Übertragung auf eine bestimmte Architektur beizutragen, andere möchten die Dokumentation verbessern und so weiter.
Dieser Schritt bietet dem Kandidaten die Möglichkeit zu erklären, was er innerhalb des Debian-Projekts zu tun beabsichtigt, und zu zeigen, was er zu diesem Zweck bereits getan hat. Debian ist ein pragmatisches Projekt, und es genügt nicht, etwas zu sagen, falls die Taten den Aussagen nicht entsprechen. Wenn die beabsichtigte Rolle innerhalb des Projekts sich auf die Paketbetreuung bezieht, wird im allgemeinen die erste Version des angehenden Pakets von einem Sponsor aus den Reihen der bereits registrierten Debian-Entwickler technisch überprüft und auf die Debian-Server hochgeladen.
Finally, the examiner checks the candidate's technical (packaging) skills with a detailed questionnaire. Bad answers are not permitted, but the answer time is not limited. All the documentation is available and several attempts are allowed if the first answers are not satisfactory. This step does not intend to discriminate, but to ensure at least a modicum of knowledge common to new contributors.
Dieser Schritt wird im Jargon der Prüfer als Aufgaben & Fähigkeiten (kurz: T&S) bezeichnet.

15.4.2.5. Endgültige Bestätigung

Im allerletzten Schritt wird der gesamte Prozess durch einen DAM (Debian Account Manager) begutachtet. Der DAM wird alle vom Prüfer über den Kandidaten zusammengetragenen Informationen nachprüfen und dann entscheiden, ob ein Konto auf den Debian-Servern eingerichtet wird oder nicht. Falls zusätzliche Informationen benötigt werden, kann die Kontoerstellung verzögert werden. Ablehnungen sind recht selten, falls der Prüfer gute Arbeit bei der Verfolgung des Vorgangs geleistet hat, aber sie kommen manchmal vor. Sie sind niemals endgültig, und der Kandidat kann es später noch einmal versuchen.
Die Entscheidung des DAM ist bindend und (fast) ohne Einspruchsmöglichkeit, woraus sich erklärt, warum die Personen in dieser Position bereits häufig kritisiert worden sind.