Debian Entwicklerreferenz

Debian Entwicklerreferenz Team <developers-reference@packages.debian.org>

• Copyright © 2019 - 2023 Holger Levsen

• Copyright © 2015 - 2020 Hideki Yamane

• Copyright © 2008 - 2015 Lucas Nussbaum

• Copyright © 2004 - 2007 Andreas Barth

• Copyright © 2002 - 2009 Raphaël Hertzog

• Copyright © 1998 - 2003 Adam Di Carlo

• Copyright © 1997 - 1998 Christian Schwarz

Dieses Handbuch ist freie Software, sie können es nach den Bedingungen der GNU General Public License wie von der Free Software Foundation veröffentlicht, Version 2 oder (nach ihrer Option) später verteilen oder verändern .

Dies wird in der Hoffnung verteilt, dass es nützlich sein wird, jedoch ohne jegliche Garantie; ohne auch nur die implizite Garantie der Marktgängigkeit oder Eignung für einen bestimmten Zweck. Weitere Informationen finden Sie in der GNU General Public License.

Eine Kopie der GNU General Public License ist in der Debian Distribution abgelegt unter /usr/share/common-licenses/GPL-2 oder im WWW auf der GNU Webseite. Sie erhalten diese es auch schriftlich bei der Free Software Foundation, Inc., 51 Franklin Street, 5. Stock, Boston, MA 02110-1301, USA.

Dies ist die Debian Entwicklerreferenz Version 13.15, veröffentlicht am 2024-11-04.

Wenn Sie diese Referenz ausdrucken möchten, sollten Sie die PDF-Version als Basis verwenden. Dieses Handbuch ist auch in einigen anderen Sprachen verfügbar.

1. Geltungsbereich dieses Dokuments

Der Zweck dieses Dokuments besteht darin, Debian-Entwicklern und -Betreuern einen Überblick über die empfohlenen Verfahren und die verfügbaren Ressourcen zu geben.

Zu den darin diskutierten Verfahren gehört, wie man Mitglied wird (Bewerbung auf eine Mitgliedschaft), wie man neue Pakete erstellt (Neue Pakete) und wie man Pakete hochlädt (Ein Paket hochladen), wie man mit Fehlerberichten umgeht (Fehlerbehandlung), wie Pakete verschoben, entfernt oder verwaist werden (Verschieben, Entfernen, Verwaisen, Adoptieren und Wiedereinführen von Paketen), wie man Pakete portiert (Portieren und portiert werden) und wie und wann Zwischenversionen von Paketen anderer Betreuer zu erstellen sind (Non-Maintainer Uploads (NMUs)).

Die in dieser Referenz besprochenen Ressourcen umfassen die Mailinglisten (Mailinglisten) und Server (Debian-Maschinen), eine Erörterung der Struktur des Debian-Archivs (Das Debian-Archiv), eine Beschreibung der unterschiedlichen Server, die das Hochladen von Paketen akzeptieren (Hochladen nach ftp-master) und eine Erörterung von Mitteln, die Paketbetreuern dabei helfen, die Qualität ihrer Pakete zu gewährleisten (Überblick über die Werkzeuge der Debian-Betreuer).

Es sollte klar sein, dass diese Referenz nicht die technischen Einzelheiten von Debian-Paketen erörtert oder wie sie erstellt werden. Ebenso wenig wird diese Referenz die Standards einzeln aufführen, die Debian-Software erfüllen muss. All diese Informationen finden Sie im Debian Policy Manual.

Weiterhin ist dieses Dokument nicht ein Ausdruck der formalen Debian-Richtlinien. Es enthält Dokumentation für das Debian-System und allgemein vereinbarte gute fachliche Gebräuche. Daher ist es nicht das, was normalerweise als ein normierendes Dokument bezeichnet wird.

2. Bewerbung auf eine Mitgliedschaft

2.1. Erste Schritte

Also, Sie haben all die Dokumentation gelesen, sind den Debian-Leitfaden für Neue Paketbetreuer durchgegangen, verstehen alles, was im Beispielpaket hello vorkommt und es geht Ihnen nun darum, Ihre Lieblings-Software zu debianisieren. Was müssen Sie denn nun im Detail tun, damit Sie Debian-Entwickler werden und Ihre Arbeit in das Debian-Projekt einfließen kann?

Falls Sie das nicht bereits getan haben, schreiben Sie sich zuerst in die Mailingliste debian-devel@lists.debian.org ein. Senden Sie hierzu das Wort subscribe im Betreff einer E-Mail an debian-devel-REQUEST@lists.debian.org. Falls es Probleme gibt, wenden Sie sich unter listmaster@lists.debian.org an den Administrator der Liste. Weitere Informationen über verfügbare Listen finden Sie unter Mailinglisten. debian-devel-announce@lists.debian.org ist eine Pflichtlektüre für jeden, der die Entwicklung von Debian verfolgen möchte.

Sie sollten sich einschreiben und ein mitlesen, ohne selbst Beiträge zu verfassen, bevor Sie irgendetwas programmieren. Teilen Sie mit, woran Sie arbeiten möchten, um doppelten Aufwand zu vermeiden.

Auch debian-mentors@lists.debian.org ist ein sinnvolles Abonnement. Lesen Sie Debian-Mentoren und -Sponsoren für Details. Der IRC-Kanal #debian kann ebenfalls hilfreich sein, siehe auch IRC-Kanäle.

Wenn Sie bereits wissen wie Sie zu Debian beitragen möchten, sollten Sie Kontakt mit existierenden Debian-Betreuern aufnehmen, die an ähnlichen Aufgaben arbeiten. Auf diesem Weg können Sie von erfahrenen Entwicklern lernen. Falls Sie zum Beispiel daran interessiert sind, existierende Software für Debian zu paketieren, sollten Sie versuchen, einen Sponsor zu finden. Ein Sponsor wird mit Ihnen zusammen an Ihrem Paket arbeiten und es in das Debian-Archiv hochladen, sobald er mit Ihrer Paketierung zufrieden ist. Sie können Sponsoren auf der Mailingliste debian-mentors@lists.debian.org finden, indem Sie dort Ihr Paket und sich selbst beschreiben und nach einem Sponsor fragen (lesen Sie bitte Pakete sponsern und https://wiki.debian.org/DebianMentorsFaq, um weitere Informationen über das Sponsern zu erhalten). Wenn Sie andererseits daran interessiert sind, Debian auf alternative Architekturen oder Kernel zu portieren, können Sie spezielle Mailinglisten zur Portierung abonnieren und dort nachfragen, wie Sie am besten einsteigen können. Und schließlich können Sie sich - falls Sie Interesse an Dokumentation oder Qualitätssicherung (QS) haben - den Betreuern anschließen, die bereits an diesen Aufgaben arbeiten, und Patches sowie Verbesserungen einreichen.

Eine Schwierigkeit könnte ein zu generischer lokaler Teil in Ihrer Mailadresse sein. Begriffe wie "mail", "admin", "root" und "master" sollten vermieden werden. Bitte lesen Sie https://www.debian.org/MailingLists/ für Details.

2.2. Debian-Mentoren und -Sponsoren

Die Mailingliste debian-mentors@lists.debian.org wurde für die Einsteiger unter den Betreuern eingerichtet, die sich um Hilfe beim Paketieren Ihrer ersten Pakete und anderen entwicklerbezogenen Themen bemühen. Jeder neu angehende Entwickler ist eingeladen, sich auf dieser Liste einzuschreiben (siehe Mailinglisten für Details).

Diejenigen die persönliche Hilfe bevorzugen (z.B. mittels privater E-Mail), sollten auch an diese Liste schreiben, und ein erfahrener Entwickler wird freiwillig helfen.

Oder, wenn Sie einige Pakete zur Aufnahme in Debian vorbereitet haben, aber darauf warten, dass Ihr Antrag auf Mitgliedschaft in Debian bearbeitet wird, finden Sie möglicherweise einen Sponsor, der Ihre Pakete für Sie hoch lädt. Sponsoren sind Personen, die offizielle Debian-Entwickler sind und bereit sind, Ihre Pakete zu kritisieren und für Sie hochzuladen. Bitte lesen Sie zuerst die FAQ zu Debian-Mentoren unter https://wiki.debian.org/DebianMentorsFaq.

Falls Sie ein Mentor und/oder Sponsor werden möchten, sind weitere Informationen in Zusammenwirken mit zukünftigen Debian-Entwicklern verfügbar.

2.3. Registrierung als Debian Mitglied

Bevor Sie sich bei Debian registrieren, ist es sehr wichtig, dass Sie alle Informationen lesen die in der New Members Corner verfügbar sind. Diese beschreiben detailliert die Vorbereitungen, die Sie treffen müssen, damit Sie sich für eine Debian-Mitgliedschaft registrieren können. Bevor Sie sich bewerben, müssen Sie beispielsweise den Debian-Gesellschaftervertrag lesen. Wenn Sie sich als Mitglied registrieren, stimmen Sie dem Debian-Gesellschaftsvertrag zu und verpflichten sich diesen einzuhalten. Es ist sehr wichtig, dass die Mitglieder mit den wesentlichen Ideen hinter Debian übereinstimmen. Es wäre auch eine gute Idee, das GNU-Manifest zu lesen.

Bei der Registrierung als Mitglied werden Ihre Identität und Absichten geprüft sowie Ihre technischen Fähigkeiten überprüft. Da die Anzahl der an Debian arbeitenden Personen auf über 1000 angewachsen ist und unsere Systeme an mehreren sehr wichtigen Orten eingesetzt werden, muss Debian vorsichtig sein um nicht kompromittiert zu werden. Daher müssen wir neue Mitglieder entsprechend überprüfen, bevor wir ihnen Konten auf unseren Servern zuweisen und diese Pakete hochladen können.

Bevor Sie sich tatsächlich registrieren, sollten Sie zeigen, dass Sie kompetent arbeiten und gute Beiträge leisten. Sie können dies zeigen, indem Sie Patches an die Debian-Fehlerdatenbank senden und für einige Zeit ein Paket betreuen, das durch einen existierenden Debian-Entwickler gesponsert wird. Außerdem wird erwartet, dass Mitwirkende sich für das ganze Projekt interessieren und nicht nur ihre eigenen Pakete betreuen. Falls Sie anderen Betreuern helfen können, weitere Informationen zu einem Fehler oder sogar einen Patch bereitzustellen, dann tun Sie dies!

Für die Registrierung ist es erforderlich, dass Sie mit der Debian-Philosophie und der technischen Dokumentation vertraut sind. Weiterhin benötigen Sie einen OpenPGP-Schlüssel, der von einem existierenden Debian-Betreuer signiert wurde. Falls Ihr OpenPGP-Schlüssel noch nicht signiert wurde, sollten Sie versuchen, einen Debian-Entwickler persönlich zu treffen, damit Ihr Schlüssel signiert wird. Es gibt eine Schlüssel Signierungskoordinations-Seite, die Ihnen helfen sollte, einen Debian-Entwickler in Ihrer Nähe zu finden. (Falls es in Ihrer Nähe keinen Debian-Entwickler gibt, können als absolute Ausnahme fallspezifisch alternative Identitätsprüfungen erlaubt werden. Lesen Sie die Texte zur Identitätsprüfung, um weitere Informationen zu erhalten.

Falls Sie noch keinen OpenPGP-Schlüssel haben, generieren Sie sich einen. Jeder Entwickler benötigt einen OpenPGP-Schlüssel, um Pakete vor den Hochladen ins Archiv signieren und verifizieren zu können. Sie sollten das Handbuch der Software lesen und kennen welche Sie paketieren, es wird wichtige und meistens auch sicherheitsrelevanten Informationen enthalten. Es sind viel mehr Sicherheitslücken auf menschliche Fehler zurückzuführen, als auf Softwarefehler oder leistungsstarke Spionagetechniken. Lesen Sie Verwalten Ihres öffentlichen Schlüssels, um weitere Informationen über die Verwaltung Ihrer öffentlichen Schlüssel zu erhalten.

Debian uses the GNU Privacy Guard (package gnupg version 2 or better) as its baseline standard. You can use some other implementation of OpenPGP as well. Note that OpenPGP is an open standard based on RFC 9580.

Die Schlüssellänge Deines Schlüssels muss mindestens 2048-Bit betragen, jedoch sollten 4096-Bit als Schlüssellänge bevorzugt werden (siehe https://keyring.debian.org/creating-key.html), es gibt keinen Grund, kürzere Schlüssel zu verwenden und dies wäre auch wesentlich unsicherer.

Falls Ihr öffentlicher Schlüssel nicht auf einem öffentlichen Server wie subkeys.pgp.net liegt, lesen Sie bitte NM Schritt 2: Identitätsprüfung. Dieses Dokument enthält Anweisungen, wie Sie Ihren Schlüssel auf öffentliche Schlüsselserver ablegen. Die "New Maintainer Group" wird Ihren öffentlichen Schlüssel auf den Servern ablegen, wenn er nicht bereits dort ist.

Einige Länder schränken den Gebrauch kryptografischer Software durch Ihre Bürger ein. Dies muss jedoch die Aktivitäten als Debian-Paketbetreuer nicht behindern, da es vollkommen legal sein kann, kryptografische Produkte für die Authentifizierung anstatt für Verschlüsselungszwecke zu verwenden. Wenn Sie in einem Land leben, in dem Kryptografie sogar für Authentifizierung verboten ist, so kontaktieren Sie bitte Debian, so dass besondere Vereinbarungen getroffen werden können.

Um sich als neues Mitglied zu bewerben, benötigen Sie einen bestätigten und aktiven Debian-Entwickler, der Ihre Bewerbung unterstützt (ein Befürworter). Nachdem Sie eine Weile zu Debian beigetragen haben und sich als registrierter Entwickler bewerben möchten, ist es notwendig das ein bestehender Entwickler, mit dem Sie in den letzten Monaten zusammengearbeitet haben, seine Überzeugung zum Ausdruck bringt, dass Sie sinnfoll zu Debian beitragen können.

Wenn Sie einen Befürworter gefunden haben, Sie ihren OpenPGP-Schlüssel signiert haben und bereits eine Weile zu Debian beigetragen haben sind die Voraussetzungen gegeben, dass Sie sich bewerben können. Sie können sich dann einfach auf unserer Bewerbungsseite registrieren. Nachdem Sie sich angemeldet haben, muss Ihr Befürworter Ihre Bewerbung bestätigen. Wenn Ihr Befürworter diesen Schritt abgeschlossen hat, wird Ihnen ein Bewerbungsmanager zugewiesen, der Sie durch die erforderlichen Schritte des Prozesses für neue Mitglieder führt. Sie können Ihren Status jederzeit auf der Bewerbungsstatuskarte überprüfen.

Weitere Informationen finden Sie auf der Debian-Website New Members Corner. Stellen Sie sicher, dass Sie mit den erforderlichen Schritten des Prozesses für neue Mitglieder vertraut sind, bevor Sie sich tatsächlich bewerben. Wenn Sie gut vorbereitet sind, können Sie später viel Zeit sparen.

3. Pflichten von Debian-Entwicklern

3.1. Pflichten von Paketbetreuern

Als Paketbetreuer sollten Sie qualitativ hochwertige Pakete bereitstellen, die gut in das System integriert sind und den Debian-Richtlinien entsprechen.

3.1.1. Auf die nächste Stable-Veröffentlichung hinarbeiten

Es ist nicht ausreichend, Pakete hoher Qualität in Unstable bereitzustellen; die meisten Anwender werden nur von Ihren Paketen profitieren, wenn Sie Teil der nächsten Stable-Veröffentlichung sind. Es wird daher von Ihnen erwartet, dass Sie mit dem Release-Team zusammenarbeiten, um sicherzustellen, dass Ihre Pakete enthalten sein werden.

Konkreter ausgedrückt: Sie sollten überwachen, ob Ihre Pakete nach Testing (siehe Die Distribution Testing) wandern. Wenn die Migration nach Ablauf der Testperiode nicht stattfindet, sollten Sie analysieren warum diese nicht erfolgt und darauf hinarbeiten, dies zu beheben. Es könnte heißen, dass Sie Ihr Paket korrigieren müssen (z.B. im Fall Release-kritischer Fehler oder wenn das Bauen auf einigen Architekturen fehlschlägt), aber es kann auch heißen, dass andere Pakete aktualisiert bzw. korrigiert (oder manchmal auch aus Testing entfernt) werden müssen, um bei einer Transition zu helfen, in denen Ihr Paket aufgrund von Abhängigkeiten involviert ist. Das Release-Team kann Ihnen einige Informationen zu den aktuellen Blockern einer bestimmten Transition geben, wenn Sie diese nicht identifizieren können.

3.1.2. Pakete in Stable betreuen

Die meiste Arbeit von Paketbetreuern geht in das Bereitstellen aktualisierter Paketversionen in Unstable, aber ihre Aufgabe bedingt auch, sich um Pakete in der aktuellen Veröffentlichung von Stable zu kümmern.

Obwohl von Änderungen in Stable abgeraten wird, sind diese dennoch möglich. Immer wenn ein Sicherheitsproblem gemeldet wird, sollten Sie mit dem Sicherheits-Team zusammenarbeiten, um eine korrigierte Version bereitzustellen (siehe Handhabung von sicherheitsrelevanten Fehlern). Wenn Fehler des Schweregrads "important" (oder höher) gemeldet werden, sollten Sie in Betracht ziehen, eine gezielte Fehlerbehebung zur Verfügung zu stellen. Sie können das Stable-Release-Team fragen, ob es eine solche Aktualisierung akzeptieren würde und dann einen stable-Upload vorbereiten (siehe Sonderfall Uploads in die Distributionen Stable und Oldstable).

3.1.3. Verwalten Release-kritischer Fehler

Sie sollten Fehlerberichte zu Ihren Paketen generell so erledigen, wie es in Fehlerbehandlung beschrieben wird. Es gibt jedoch eine spezielle Fehlerkategorie, auf die Sie besonders Acht geben sollten – sogenannte Release-kritische Fehler (release critical bugs/RC-Fehler). Alle Fehlerberichte mit Schweregrad critical, grave oder serious machen das Paket ungeeignet für eine Aufnahme in die nächste Stable-Veröffentlichung. Sie können daher die Debian-Veröffentlichung verzögern (wenn sie ein Paket in Testing beeinflussen) oder Migrationen nach Testing blockieren (wenn sie nur ein Paket in Unstable beeinflussen). Im schlechtesten Fall führen sie zum Entfernen des Pakets. Daher müssen diese Fehler so schnell wie möglich behoben werden.

Falls Sie aus irgend einem Grund nicht in der Lage sind, den Fehler in einem Paket innerhalb von zwei Wochen zu beheben (zum Beispiel aus Termingründen oder weil er schwer zu beheben ist), sollten Sie es klar im Fehlerbericht vermerken und den Fehler mit help kennzeichnen, um Freiwillige einzuladen, sich einzubringen. Seien Sie sich bewusst, dass Release-kritische Fehler oft das Ziel von Uploads durch Nicht-Betreuer ("Non-Maintainer Uploads", siehe Non-Maintainer Uploads (NMUs)) sind, da sie die Migration vieler Pakete nach Testing blockieren können.

Mangel an Aufmerksamkeit gegenüber Release-kritischen Fehlern wird vom QA-Team oft als Zeichen interpretiert, dass der Betreuer verschwunden ist, ohne sein Paket ordentlich zu verwaisen. Das MIA-Team (Missing In Action Team) könnte außerdem eingeschaltet werden, was dazu führen könnte, dass Ihre Pakete verwaist werden (siehe Sich mit inaktiven und/oder nicht erreichbaren Paketbetreuern beschäftigen).

3.1.4. Abstimmung mit Originalautoren

Ein großer Teil Ihrer Arbeit als Debian-Betreuer wird darin bestehen, mit den Upstream-Entwicklern in Kontakt zu bleiben. Benutzer von Debian melden manchmal Fehler, die nicht spezifisch für die Debian Distribution sind, an unser Fehlerverfolgungssystem (oft BTS genannt was Bug Tracking System bedeutet). Diese Fehlerberichte sollten an die Upstream-Entwickler weitergeleitet werden, damit diese in einer zukünftigen Upstream-Version behoben werden können. Normalerweise ist es am besten, wenn Sie dies tun können, aber alternativ können Sie auch den Fehler-Übermittler bitten dies zu tun.

Obwohl es nicht Ihre Arbeit ist nicht Debian-spezifische Fehler zu beheben, können Sie dies dennoch tun, wenn Sie dazu in der Lage sind. Wenn Sie solche Fehler beheben, stellen Sie sicher, dass Sie ihre Korrekturen auch an die ursprünglichen Betreuer weiterleiten. Debian-Anwender und -Entwickler werden manchmal Patches schicken, um Fehler im Ursprungsprogramm zu beheben – Sie sollten diese Patches auswerten und an die ursprünglichen Autoren weiterleiten.

In Fällen, in denen ein Fehlerbericht nach Upstream weitergeleitet wird, kann es hilfreich sein, dass der BTS-Link-Dienst zur Synchronisierung von Bug-Reports zwischen dem Upstream- und dem Debian BTS-Dienst benutzt wird.

Falls Sie die ursprünglichen Quellen verändern müssen, um ein den Richtlinien entsprechendes Paket zu erstellen, dann sollten Sie freundlich eine Korrektur vorschlagen, die dort eingefügt werden kann, so dass Sie den Quellcode bei der nächsten Version der Originalautoren nicht ändern müssen. Ganz gleich, welche Änderungen Sie möchten – versuchen Sie ein Forken vom ursprünglichen Quellcode zu vermeiden.

Wenn Sie der Ansicht sind, dass die ursprünglichen Entwickler Debian oder der Gemeinschaft rund um freie Software ablehnend gegenüber stehen, könnten Sie es sich nochmal überlegen, ob Sie die Software in Debian einbringen möchten. Manchmal sind die gesellschaftlichen Kosten höher, als der Gewinn, den die Software mitbringt.

3.2. Verwaltungspflichten

Ein Projekt der Größe von Debian beruht auf einer Verwaltungsinfrastruktur, um über alles den Überblick zu behalten. Als Projektmitglied haben Sie einige Pflichten, um sicherzustellen, dass alles reibungslos läuft.

3.2.1. Verwaltung Ihrer Debian-Informationen

Es gibt unter https://db.debian.org/ eine LDAP-Datenbank, die Informationen über Debian-Entwickler enthält. Sie sollten Ihre Informationen dort eintragen und bei Änderungen aktualisieren. Stellen Sie insbesondere sicher, dass Ihre Weiterleitungsadresse für Ihre debian.org E-Mail Adresse immer aktuell ist. Das gilt auch für die Adresse, zu der Ihre "debian-private" E-Mails versendet werden, wenn Sie sich auch dort angemeldet haben.

Um weitere Informationen über die Datenbank zu erhalten, lesen Sie bitte Die Entwicklerdatenbank.

3.2.2. Verwalten Ihres öffentlichen Schlüssels

Gehen Sie sehr vorsichtig mit Ihren privaten Schlüsseln um. Legen Sie sie nicht auf öffentlichen Servern oder Maschinen mit mehreren Benutzern ab, wie den Debian-Servern (siehe Debian-Maschinen). Sichern Sie Ihre Schlüssel. Behalten Sie eine Kopie offline. Lesen Sie die Dokumentation, die Ihrer Software beiliegt. Lesen Sie die PGP FAQ und OpenPGP: optimales Vorgehen.

Sie müssen nicht nur dafür sorgen, dass Ihr Schlüssel sicher vor Diebstahl ist, sondern auch, dass er nicht verloren geht. Generieren Sie Ihr Widerrufs-Zertifikat und erstellen Sie eine Kopie davon (am besten in Papierform). Dies wird benötigt, wenn Sie Ihren Schlüssel verloren haben.

Falls Sie Ihrem öffentlichen Schlüssel Signaturen oder Benutzerkennungen hinzufügen, können Sie den Debian-Schlüsselring aktualisieren, indem Sie Ihren Schlüssel an den Schlüsselserver unter keyring.debian.org senden. Aktualisierungen werden mindestens einmal monatlich von den debian-keyring-Paketbetreuern bearbeitet.

Wenn Sie einen komplett neuen Schlüssel hinzufügen oder einen alten entfernen möchten, benötigen Sie den durch einen anderen Entwickler neu signierten Schlüssel. Falls der alte Schlüssel kompromittiert oder ungültig ist, müssen Sie außerdem das Widerrufs-Zertifikat hinzufügen. Falls es keinen vernünftigen Grund für einen neuen Schlüssel gibt, können die Betreuer des Schlüsselrings den neuen Schlüssel ablehnen. Details finden Sie unter https://keyring.debian.org/replacing_keys.html.

Es werden die gleichen Schlüssel-Extrahierungsroutinen angewandt, wie sie unter Registrierung als Debian Mitglied besprochen wurden.

Eine weiterreichende Erörterung der Debian-Schlüsselverwaltung können Sie in der Dokumentation des Pakets debian-keyring und auf https://keyring.debian.org/ finden.

3.2.3. Abstimmungen

Obwohl Debian nicht wirklich demokratisch ist, werden demokratische Prozesse benutzt, um das Führungspersonal zu wählen und generellen Entschlüssen zuzustimmen. Diese Prozeduren sind durch die Debian-Verfassung definiert.

Im Gegensatz zur jährlichen Wahl des Projektleiters werden keine regelmäßigen Abstimmungen abgehalten und wenn doch, dann nicht einfach so. Jeder Vorschlag wird zuerst auf der Mailingliste debian-vote@lists.debian.org besprochen und benötigt mehrere Befürworter, bevor der Projektsekretär die Abstimmungsprozedur in Gang setzt.

Sie müssen vor der Abstimmung nicht alle Diskussionen verfolgen, da der Sekretär mehrere Aufrufe zur Abstimmung auf debian-devel-announce@lists.debian.org heraus gibt (und von allen Entwicklern wird erwartet, dass sie diese Liste abonniert haben). Demokratie funktioniert nicht richtig, wenn die Leute nicht an Abstimmungen teilnehmen, daher wird allen Entwicklern empfohlen abzustimmen. Die Abstimmung wird mittels OpenPGP-signierter/verschlüsselter E-Mails durchgeführt.

Die Liste aller (früheren und aktuellen) Vorschläge ist auf der Seite Debian-Abstimmungs-Informationen verfügbar, ebenso die Informationen, wie Vorschläge gemacht und unterstützt werden und darüber abgestimmt wird.

3.2.4. Elegant Urlaub machen

Es ist bei Entwicklern üblich, dass es Zeiten gibt, in denen sie abwesend sind, entweder wegen geplanter Ferien oder einfach, weil sie unter anderer Arbeit begraben sind. Am wichtigsten ist, dass Sie daran denken, andere Entwickler über Ihren Urlaub zu informieren, damit diese bei Problemen mit Ihren Paketen oder anderweitigen Pflichten im Projekt die erforderlichen Maßnahmen ergreifen können.

Üblicherweise bedeutet dies, dass andere Entwickler ein NMU (siehe Non-Maintainer Uploads (NMUs)) Ihres Pakets durchführen dürfen, weil ein großes Problem (release-kritischer Fehler, Sicherheitsaktualisierung etc.) auftritt, während Sie in Ferien sind. Manchmal sind es auch weniger kritische Dinge, wegen derer Sie verhindert sein können, aber es ist trotzdem angemessen, andere darüber zu informieren.

Um andere Entwickler zu informieren, gibt es zwei Dinge die Sie tun sollten. Zuerst senden Sie eine E-Mail an debian-private@lists.debian.org, in der Sie [VAC] vor den Betreff Ihrer Nachricht schreiben [1] und die Dauer angeben, wie lange Sie Urlaub machen. Sie können außerdem einige besondere Anweisungen geben, was beim Auftreten von Fehlern zu tun ist.

Das andere was Sie tun sollten, ist sich selbst in der Die Entwicklerdatenbank als abwesend zu kennzeichnen (auf diese Information können nur Debian-Entwickler zugreifen). Vergessen Sie nicht, die Urlaubskennzeichnung zu entfernen, wenn Sie wieder zurück sind!

Idealerweise sollten Sie sich auf den OpenPGP-Koordinierungsseiten anmelden, wenn Sie Urlaub buchen und prüfen, ob es dort jemanden gibt, der eine Signatur benötigt. Dies ist besonders dann wichtig, wenn Leute an exotische Orte fahren, an denen es noch keine Entwickler gibt, aber Leute, die an einer Bewerbung interessiert sind.

3.2.5. Sich zurückziehen

Falls Sie das Debian-Projekt verlassen wollen, sollten Sie die folgenden Schritte einhalten:

• Verwaisen Sie all Ihre Pakete wie in Verwaisen von Paketen beschrieben.

• Entfernen Sie sich aus Uploader-Feldern für Co- oder Team-betreute Pakete.

• Falls Sie E-Mails über einen "@debian.org" E-Mail Alias (z.B. press@debian.org) empfangen haben und möchten aus diesem entfernt werden, öffnen Sie ein RT-Ticket für die Debian-Systemadministration. Senden Sie dazu eine E-Mail an admin@rt.debian.org, die irgendwo im Betreff "Debian RT" enthält und angibt, von welchen Alias Sie entfernt werden möchten.

• Bitte denken Sie daran, sich auch aus Teams zurückzuziehen, z.B. entferne Dich von Team-Wiki-Seiten oder Salsa-Gruppen.

• Verwenden Sie den Link https://nm.debian.org/process/emeritus, um sich auf nm.debian.org anzumelden, den Emeritus-Status anzufordern und eine Abschiedsnachricht zu schreiben, die automatisch auf debian-private Mailingliste veröffentlicht wird.

  Für die Authentifizierung an der NM-Seite ist ein SSO-Browserzertifikat erforderlich. Sie können diese auf https://sso.debian.org generieren.

  Wenn Sie Probleme haben, den Ruhestand selbst zu starten, kontaktieren sie über nm@debian.org das NM-Frontdesk.

Es ist wichtig obigem Prozess zu folgen, da die Suche nach inaktiven Entwicklern und das Verwaisen derer Pakete erhebliche Zeit kostet und Mühe bereitet.

3.2.6. Nach dem Ausscheiden zurückkehren

Das Konto eines zurückgetretenen Entwicklers ist als "Emeritus" markiert, wenn dem Prozess in Sich zurückziehen gefolgt wurde und ansonsten als "Removed". Zurückgetretene Entwickler mit einem "Emeritus"-Konto können Ihr Konto wie folgt reaktivieren:

• Zugang zu einem Salsa Account erhalten (entweder indem Sie sich die Anmeldeinformationen für Ihr altes Gastkonto gemerkt haben oder indem Sie ein neues Konto anfordern, welches auf der SSO Debian Wikiseite beschrieben ist.

• Schreiben einer E-Mail an nm@debian.org zum Erhalt weitere Anweisungen.

• Durchlaufen Sie den verkürzten NM-Prozess (um sicherzustellen, dass der zurückgekehrte Entwickler noch immer die wichtigen Teile von P&P – "Philosophie und Prozeduren" und T&S – "Aufgaben und Fertigkeiten" kennt).

Zurückgetretene Entwickler mit einem "Removed" Konto müssen den NM-Prozess erneut durchlaufen.

[1]

Der Grund hierfür ist, dass die Nachricht einfach von Leuten ausgefiltert werden kann, die keine Urlaubsbenachrichtigungen lesen möchten.

4. Ressourcen für Debian Mitglieder

In diesem Kapitel finden Sie eine sehr kurze Roadmap der Debian-Mailinglisten, der Debian-Maschinen, die Ihnen als Mitglied zur Verfügung stehen, und aller anderen Ressourcen, die Ihnen bei Ihrer Arbeit zur Verfügung stehen.

4.1. Mailinglisten

Viele Unterhaltungen zwischen Debian-Entwicklern (und Anwendern) laufen über ein weites Feld von Mailinglisten, die auf lists.debian.org untergebracht sind. Mehr darüber, wie Sie diese Listen abonnieren oder abbestellen können, wie Sie Nachrichten abschicken, wo Sie alte Nachrichten finden und suchen können, wie Sie Listenbetreuer kontaktieren können sowie verschiedene sonstige Informationen über Mailinglisten erfahren finden Sie auf https://www.debian.org/MailingLists/. Dieser Abschnitt wird nur die Gesichtspunkte der Mailinglisten aufzeigen, die von besonderem Interesse für Entwickler sind.

4.1.1. Grundregeln für die Benutzung

Wenn Sie auf Nachrichten auf der Mailingliste antworten, senden Sie bitte keine Kopie (CC) an den ursprünglichen Verfasser, außer, wenn dieser explizit darum bittet. Jeder, der an eine Mailingliste schreibt, sollte sie lesen, um die Antworten zu sehen.

Kreuzversand (die gleiche Nachricht an mehrere Listen senden) ist unerwünscht. Kürzen Sie, wie immer im Netz, die Zitate von Artikeln, auf die Sie antworten. Halten Sie sich bitte an die allgemeinen Gepflogenheiten beim Versand von Nachrichten.

Bitte lesen Sie den Leitfaden, um weitere Informationen zu erhalten. Die Debian Community Guidelines sind es ebenfalls wert, gelesen zu werden.

4.1.2. Haupt-Entwickler-Mailinglisten

Die Haupt-Debian-Mailinglisten, die Entwickler nutzen sollten, sind:

• debian-devel-announce@lists.debian.org, wird benutzt, um Entwicklern wichtige Dinge anzukündigen. Es wird von allen Entwicklern erwartet, dass sie diese Liste abonnieren.

• debian-devel@lists.debian.org, wird benutzt, um über verschiedene entwicklungsbezogene technische Themen zu reden.

• debian-policy@lists.debian.org, wird benutzt, um über die Debian-Richtlinien zu diskutieren und darüber abzustimmen.

• debian-project@lists.debian.org, wird benutzt, um über verschiedene entwicklungsbezogene, nicht technische Themen zu reden.

Es sind weitere Mailinglisten für unterschiedliche spezielle Themen verfügbar. Eine Liste finden Sie unter https://lists.debian.org/.

4.1.3. Spezielle Listen

debian-private@lists.debian.org ist eine besondere Mailingliste für private Unterhaltungen zwischen Debian-Entwicklern. Das heißt, sie sollte benutzt werden, um über Dinge zu reden, die aus irgend einem Grund nicht veröffentlicht werden sollen. Eigentlich ist es eine Liste mit geringem Umfang und Benutzer werden angehalten, debian-private@lists.debian.org nicht zu benutzen, so lange es nicht wirklich nötig ist. Leiten Sie außerdem keine E-Mail von dieser Liste an jemanden weiter. Es sind aus naheliegenden Gründen keine Archive dieser Liste im Web verfügbar, aber Sie können sie sehen, indem Sie Ihr Shell-Konto auf master.debian.org benutzen und in das Verzeichnis ~debian/archive/debian-private/ schauen.

debian-email@lists.debian.org ist eine besondere Mailingliste, die als Wundertüte für Debian-bezogene Korrespondenz, wie den Kontakt zu ursprünglichen Autoren über Lizenzen, Fehler, etc. oder Diskussionen über das Projekt mit anderen benutzt wird, wobei es nützlich sein könnte, dass die Diskussion irgendwo archiviert wird.

4.1.4. Antrag auf neue entwicklungsbezogene Listen

Bevor Sie eine Mailingliste anfordern, die sich auf die Entwicklung eines Pakets (oder einer kleinen Gruppe verwandter Pakete) bezieht, sollten Sie überlegen, ob die Verwendung eines Alias eventuell besser geeignet wäre. So ein Alias wird durch einen Eintrag in eine .forward-aliasname-Datei auf master.debian.org angelegt, der dann eine Ihr-Aliasname@debian.org E-Mail Adresse gewissermaßen übersetzt.

Falls Sie entscheiden, dass eine reguläre Mailingliste auf lists.debian.org wirklich das ist was Sie wollen – nur zu. Füllen Sie eine Anfrage aus und folgen Sie diesem HOWTO.

4.2. IRC-Kanäle

Mehrere IRC-Kanäle sind für die Entwicklung von Debian bestimmt. Sie werden hauptsächlich auf dem Open and free technology community (OFTC)-Netzwerk gehostet. Der DNS-Eintrag irc.debian.org ist ein Alias für irc.oftc.net.

Der Hauptkanal für Debian ist im Allgemeinen #debian. Dies ist ein großer Kanal für allgemeine Zwecke, auf dem Benutzer aktuelle Neuigkeiten im Inhalt finden, der von Robotern bereitgestellt wird. #debian ist für englischsprachige Nutzer. Es gibt auch #debian.de, #debian-fr, #debian-br und andere Kanäle mit ähnlichen Namen für anderssprachige Nutzer.

Der Hauptkanal für die Debian-Entwicklung ist #debian-devel. Es ist ein sehr aktiver Kanal; es werden normalerweise mindestens 150 Leute zu jeder Tageszeit dort sein. Es ist ein Kanal für Leute, die an Debian arbeiten, es ist kein Support-Kanal (dafür gibt es #debian). Das Themengebiet enthält normalerweise interessante Informationen für Entwickler.

Da #debian-devel ein offener Kanal ist, sollten Sie dort nicht über Probleme sprechen, die in debian-private@lists.debian.org diskutiert werden. Es gibt einen anderen Kanal für diesen Zweck. Er heißt #debian-private und ist durch einen Schlüssel geschützt. Dieser Schlüssel ist unter master.debian.org:~debian/misc/irc-password verfügbar.

Es gibt andere zusätzliche Kanäle, die besonderen Themen gewidmet sind. #debian-bugs wird für die Koordination von Bug-Squashing-Parties benutzt. #debian-boot wird benutzt, um die Arbeit am Debian-Installationsprogramm zu koordinieren. #debian-doc wird gelegentlich benutzt, um über die Dokumentation zu reden, wie beispielsweise über das Dokument was Sie aktuell gerade lesen. Andere Kanäle beschäftigen sich mit einer Architektur oder einer Zusammenstellung von Paketen: #debian-kde, #debian-dpkg, #debian-perl, #debian-python...

Es existieren außerdem einige nicht englische Entwicklerkanäle, zum Beispiel #debian-devel-fr für französchischsprachige Leute, die an der Entwicklung von Debian interessiert sind.

Speziell Debian gewidmete Kanäle gibt es auch in anderen IRC-Netzwerken.

4.3. Dokumentation

Dieses Dokument enthält viele Informationen, die für Debian-Entwickler nützlich sind, es kann aber auch nicht alles enthalten. Die meisten anderen interessanten Dokumente sind in der Entwickler-Ecke verlinkt. Nehmen Sie sich die Zeit alle diese Verweise zu durchstöbern – Sie werden viele weitere Dinge lernen.

4.4. Debian-Maschinen

Debian hat mehrere Computer, die als Server fungieren, die meisten davon, um kritische Funktionen für das Debian-Projekt bereitzustellen. Die meisten dieser Maschinen werden für Portierungzwecke benutzt und alle haben eine permanente Verbindung ins Internet.

Einige der Maschinen stehen einzelnen Entwicklern so lange zur Verfügung, wie die Entwickler die Regeln befolgen, die in den Debian-Rechner Benutzungsrichtlinien festgelegt wurden.

Allgemein gesprochen können Sie diese Maschinen nach Belieben für Debian-bezogene Zwecke nutzen. Bitte seien Sie freundlich zu den Systemadministratoren und verbrauchen Sie nicht massenhaft Plattenplatz, Netzwerk-Bandbreite oder CPU, ohne zuerst die Zustimmung der Systemadministratoren eingeholt zu haben. Üblicherweise werden diese Maschinen von Freiwilligen betrieben.

Bitte achten Sie darauf, Ihre Debian-Passwörter und SSH-Schlüssel, die auf Debian-Maschinen installiert sind, zu schützen. Vermeiden Sie Methoden zum Anmelden oder Hochladen, die Passwörter unverschlüsselt über das Internet übertragen, wie Telnet, FTP, POP, etc.

Bitte legen Sie kein Material auf Debian-Servern ab, das keinen Bezug zu Debian hat, nicht einmal, wenn Sie eine vorrangige Berechtigung haben.

Die aktuelle Liste von Debian-Maschinen ist unter https://db.debian.org/machines.cgi verfügbar. Diese Web-Seite enthält Maschinennamen, Kontaktinformationen darüber, wer sich anmelden kann, SSH-Schlüssel etc.

Falls Sie ein Problem mit einer Transaktion auf einem Debian-Server haben und der Ansicht sind, dass die Systemverwalter über dieses Problem informiert werden sollten, können Sie die Liste offener Probleme in der Warteschlange des DSA-Teams (Debian System Administration) vom Request Tracker unter https://rt.debian.org/ prüfen (Sie können sich als Benutzer "debian" anmelden, dessen Passwort ist unter master.debian.org:~debian/misc/rt-password verfügbar). Um ein neues Problem zu melden, senden Sie einfach eine E-Mail an admin@rt.debian.org und stellen Sie sicher, dass der Betreff die Zeichenkette "Debian RT" enthält. Um das DSA-Team per E-Mail zu kontaktieren, verwenden Sie für alles, was private oder vertrauliche Informationen enthält und die nicht veröffentlicht werden soll die Adresse dsa@debian.org, für alles andere benutzen Sie bitte debian-admin@lists.debian.org. Das DSA-Team ist auch auf dem IRC-Kanal #debian-admin im OFTC erreichbar.

Falls Sie ein Problem mit einem bestimmten Dienst haben, der sich nicht auf die Systemadministration bezieht (wie beispielsweise Pakete, die aus dem Archiv entfernt werden sollen, Vorschläge für die Website, etc.) schreiben Sie einen Fehlerbericht zu einem "Pseudo-Paket". Informationen darüber, wie Sie Fehlerberichte versenden, finden Sie unter Fehler berichten.

Einige der Hauptserver werden eingeschränkt, aber die Informationen von dort werden auf einen anderen Server gespiegelt.

4.4.1. Der Bug-Tracking-Server

bugs.debian.org ist der anerkannte Ort für die Fehlerdatenbank, das BTS (Bug Tracking System).

Falls Sie statistische Auswertungen oder Verarbeitungen von Debian-Fehlern planen, wäre dies der richtige Ort dafür. Bitte schildern Sie indes Ihre Pläne auf debian-devel@lists.debian.org bevor Sie etwas implementieren, um unnötige Doppelarbeit oder vergeudete Ausführungszeit zu vermeiden.

4.4.2. Der FTP-Master-Server

Auf dem Server ftp-master.debian.org liegt die autorisierte Kopie des Debian-Archivs. Generell landen nach ftp.upload.debian.org hochgeladene Pakete auf diesem Server, siehe Ein Paket hochladen.

Dieser Server ist einer wie oben erwähnt einer der eingeschränkten Server; ein Spiegel ist auf mirror.ftp-master.debian.org verfügbar.

Probleme mit dem Debian-Archiv müssen generell als Fehler des Pseudo-Pakets ftp.debian.org oder per E-Mail an ftpmaster@debian.org gemeldet werden, aber sehen Sie sich auch die Vorgehensweisen in Verschieben, Entfernen, Verwaisen, Adoptieren und Wiedereinführen von Paketen an.

4.4.3. Der WWW-Master-Server

Der Haupt-Webserver ist www-master.debian.org. Auf ihm liegen die offiziellen Web-Seiten, für die meisten Neulinge "das Gesicht von Debian".

Falls Sie ein Problem mit dem Debian-Webserver finden, sollten Sie generell einen Fehlerbericht an das Pseudo-Paket www.debian.org senden. Denken Sie daran zu prüfen, ob bereits sonst jemand dieses Problem an die Fehlerdatenbank gemeldet hat.

4.4.4. Der people-Webserver

people.debian.org ist der Server, der für die eigenen Web-Seiten der Entwickler über alles Mögliche mit Bezug zu Debian benutzt wird.

Falls Sie Debian spezifische Informationen haben, die Sie im Web bereitstellen möchten, können Sie dies realisieren, indem Sie das Material im Verzeichnis public_html in Ihrem Home-Verzeichnis auf people.debian.org ablegen. Es kann über die URL https://people.debian.org/~Ihre-Benutzer-ID/ darauf zugegriffen werden.

Sie sollten nur diesen besonderen Ort benutzen, da Datensicherungen davon erstellt werden, was auf anderen Rechnern nicht der Fall wäre.

Der einzige Grund, andere Rechner zu benutzen, ist üblicherweise, wenn Sie Materialien veröffentlichen möchten, die den U.S.-Exportbeschränkungen unterliegen. In diesem Fall können Sie Server benutzen, die sich außerhalb der Vereinigten Staaten befinden.

Senden Sie eine E-Mail an debian-devel@lists.debian.org, falls Sie Fragen haben.

4.4.5. salsa.debian.org: Git Repositorys und kollaborative Entwicklungsplattform

Wenn Sie ein Git-Repository für eine Ihrer Debian-Arbeiten verwenden möchten, können Sie zu diesem Zweck die GitLab-Instanz von Debian mit dem Namen Salsa verwenden. GitLab bietet auch die Möglichkeit, Merge-Requests, Wiki-Seiten, Bug-Tracker und viele andere Dienste sowie eine detaillierte Optimierung der Zugriffsberechtigungen bereitzustellen, um die Zusammenarbeit an Projekten zu unterstützen.

Für mehr Informationen besuchen Sie bitte https://wiki.debian.org/Salsa/Doc.

Jedes Debian-Paket, das auf Salsa gehostet wird, hat ebenfalls Zugang zu der Salsa-CI . Die Salsa-CI-Pipeline imitiert die Tests, die nach jedem Upload zu Debian ausgeführt werden. Aber anstatt auf die Ergebnisse warten zu müssen oder die Qualität der Debian Repositorys zu riskieren, gibt die Salsa CI direkte Rückmeldung zu allen Problemen, die Ihre Änderungen verursacht oder behoben haben.

4.4.6. GitHub.com: Senden von Pull-Anfragen an Upstream-Repositorys

Sollte ein Upstream-Repository auf GitHub.com beheimatet sein dann kann die Debian Organisation benutzt werden um einen Fork des Repository für Pull-Requests an das Upstream-Projekt erstellen zu können.

Die Organisation ist offen für alle Debian Mitglieder. Um eine Mitgliedschaft zu beantragen muss ein Issue im Debian/.github Meta Repository erstellt werden.

4.4.7. Chroots auf andere Distributionen

Auf einigen Maschinen sind Chroots für unterschiedliche Distributionen verfügbar. Sie können sie wie folgt nutzen:

vore$ dchroot unstable
Executing shell in chroot: /org/vore.debian.org/chroots/user/unstable

In allen Chroots sind die normalen Home-Verzeichnisse der Benutzer verfügbar. Sie können mittels https://db.debian.org/machines.cgi herausfinden, welche Chroots verfügbar sind.

4.5. Die Entwicklerdatenbank

Die Entwicklerdatenbank unter https://db.debian.org/ ist ein LDAP-Verzeichnis zur Verwaltung von Debian-Entwicklereigenschaften. Sie können diese Ressource benutzen, um eine Liste der Debian-Entwickler zu durchsuchen. Ein Teil dieser Informationen ist auch durch den Dienst "finger" auf Debian-Servern verfügbar. Versuchen Sie finger ihr-benutzername@db.debian.org, um zu sehen, was er berichtet.

Entwickler können sich in der Datenbank anmelden, um verschiedene Informationen über sich selbst zu ändern, wie beispielsweise:

• Die Einstellungen der Weiterleitung ihrer debian.org E-Mail-Adresse als auch das Behandeln von Spam. Siehe https://db.debian.org/forward.html für eine Beschreibung aller Optionen.

• Die Anmeldung zu debian-private

• Ob Sie in Urlaub sind

• Persönliche Informationen, wie Ihre Adresse, das Land, Längen- und Breitengrad Ihres Wohnortes für die Weltkarte der Entwickler, Telefon- und Faxnummern, IRC-Nickname und Homepage

• Passwort und bevorzugte Shell auf Maschinen des Debian-Projekts

Natürlich kann nicht auf die meisten der Informationen durch die Öffentlichkeit zugegriffen werden. Lesen Sie für weitere Informationen die Dokumentation unter https://db.debian.org/doc-general.html.

Entwickler können auch ihre SSH-Schlüssel senden, die für die Authentifizierung auf den offiziellen Debian-Maschinen benutzt werden und sogar neue *.debian.net-DNS-Einträge hinzufügen. Diese Funktionen sind unter https://db.debian.org/doc-mail.html dokumentiert.

4.6. Das Debian-Archiv

Die Distribution Debian besteht aus vielen Paketen (aktuell rund 30000 Quellpakete) und ein paar zusätzlichen Dateien (wie beispielsweise Dokumentation und Images von Installationsmedien).

Hier ist ein Beispielverzeichnisbaum eines kompletten Debian-Archivs:

dists/stable/main/
dists/stable/main/binary-amd64/
dists/stable/main/binary-armel/
dists/stable/main/binary-i386/
     ...
dists/stable/main/source/
     ...
dists/stable/main/disks-amd64/
dists/stable/main/disks-armel/
dists/stable/main/disks-i386/
     ...

dists/stable/contrib/
dists/stable/contrib/binary-amd64/
dists/stable/contrib/binary-armel/
dists/stable/contrib/binary-i386/
     ...
dists/stable/contrib/source/

dists/stable/non-free/
dists/stable/non-free/binary-amd64/
dists/stable/non-free/binary-armel/
dists/stable/non-free/binary-i386/
     ...
dists/stable/non-free/source/

dists/stable/non-free-firmware/
dists/stable/non-free-firmware/binary-amd64/
dists/stable/non-free-firmware/binary-armel/
dists/stable/non-free-firmware/binary-i386/
     ...
dists/stable/non-free-firmware/source/

dists/testing/
dists/testing/main/
     ...
dists/testing/contrib/
     ...
dists/testing/non-free/
     ...
dists/testing/non-free-firmware/
     ...

dists/unstable
dists/unstable/main/
     ...
dists/unstable/contrib/
     ...
dists/unstable/non-free/
     ...
dists/unstable/non-free-firmware/
     ...

pool/
pool/main/a/
pool/main/a/apt/
     ...
pool/main/b/
pool/main/b/bash/
     ...
pool/main/liba/
pool/main/liba/libalias-perl/
     ...
pool/main/m/
pool/main/m/mailx/
     ...
pool/non-free/d/
pool/non-free/d/doc-rfc/
     ...
pool/non-free-firmware/f/
pool/non-free-firmware/f/firmware-nonfree/
     ...

Wie Sie sehen können, enthält das Verzeichnis auf der obersten Ebene die beiden Verzeichnisse dists/ und pool/. Letzteres ist ein "Pool", in dem sich die Pakete derzeit befinden. Er wird von der Archiv-Verwaltungsdatenbank und den beiliegenden Programmen gehandhabt. Ersteres enthält die Distributionen stable, testing und unstable. Die Dateien Packages und Sources in den Distributions-Unterverzeichnissen können auf Dateien im Verzeichnis pool/ verweisen. Der Verzeichnisbaum unterhalb jeder Distribution ist auf die gleiche Art angeordnet. Was im Folgenden für stable beschrieben wird, ist gleichermaßen auf die Distributionen unstable und testing anwendbar.

dists/stable enthält drei Verzeichnisse, nämlich main, contrib und non-free und non-free-firmware.

In jedem Bereich gibt es ein Verzeichnis für Quellpakete (source) und ein Verzeichnis für jede unterstützte Architektur (binary-i386, binary-amd64, etc.).

Der Bereich main enthält zusätzliche Verzeichnisse, die die Medien-Images und einige notwendige Teile der Dokumentation, die zum Installieren der Debian-Distribution auf einer speziellen Architektur (disks-i386, disks-amd64, etc.) benötigt werden.

4.6.1. Bereiche

Der Bereich main des Debian-Archivs ist das, was die offizielle Debian-Distribution ausmacht. Der Bereich main ist offiziell, da er alle Richtlinien vollständig erfüllt. Bei den beiden anderen Abschnitten ist dies zu einem unterschiedlichen Grad nicht der Fall. Von daher sind sie nicht offizieller Teil von Debian.

Jedes Paket im Bereich "main" muss vollständig die Debian-Richtlinien für Freie Software (DFSG) erfüllen sowie alle anderen Anforderungen des Regelwerks, das im Debian Policy Manual beschrieben wurde. Die DFSG sind Debians Definition von "freier Software". Prüfen Sie das Debian Policy Manual für Details.

Pakete im Bereich contrib müssen den DFSG entsprechen, könnten aber an anderen Anforderungen scheitern. Zum Beispiel könnten sie von unfreien Paketen abhängen.

Pakete die nicht die DFSG erfüllen, werden in den Bereich non-free oder non-free-firmware platziert. Diese Pakete werden nicht als Teil der Debian-Distribution betrachtet, obwohl ihre Benutzung ermöglicht und die Infrastruktur (wie die Fehlerdatenbank und die Mailinglisten) für unfreie Pakete bereitgestellt wird.

Das Debian Policy Manual enthält eine genauere Definition dieser vier Bereiche. Die vorhergehende Erläuterung ist nur eine Einführung.

Die Unterteilung in vier Bereiche auf der obersten Ebene des Archivs ist für all die Leute wichtig, die Debian weitergeben möchten, entweder über FTP-Server im Internet oder auf CD-ROMs: Rechtliche Risiken können vermieden werden, wenn nur die Abschnitte main und contrib weitergegeben werden. Einige Pakete im Bereich non-free erlauben zum Beispiel keine kommerzielle Weitergabe.

Andererseits könnte ein CD-ROM-Verkäufer die einzelnen Paketlizenzen der Pakete in non-free leicht prüfen und seinen CD-ROMs so viele wie erlaubt hinzufügen. (Da dies von Verkäufer zu Verkäufer stark variiert, können Debian-Entwickler diese Arbeit nicht erledigen.)

Beachten Sie, dass der Begriff Bereich auch im Bezug auf Kategorien benutzt wird, um die Organisation und das Durchstöbern verfügbarer Pakete zu vereinfachen, z.B. admin, net, utils etc. Diese Bereiche (eher Unterbereiche) existierten irgendwann einmal in der Form von Unterverzeichnissen innerhalb des Debian-Archivs. Heutzutage existieren sie nur noch in den "Section"-Kopfzeilenfeldern der Pakete.

4.6.2. Architekturen

In den Anfangstagen war der Linux-Kernel und somit Debian nur für die Intel-i386-Plattformen (oder höher) verfügbar. Aber als Linux zunehmend populärer wurde, wurde der Kernel auf andere Architekturen portiert und Debian begann, diese zu unterstützen. Und als ob die Unterstüzung so viel verschiedener Hardware noch nicht genug wäre, entschied Debian, einige Portierungen zu erstellen, die auf anderen Unix-Kerneln beruhten, wie hurd und kfreebsd.

Debian GNU/Linux 1.3 war nur für i386 verfügbar. Debian 2.0 wurde für die Architekturen i386 und m68k ausgegeben. Debian 2.1 kam für die Architekturen i386, m68k, alpha und sparc heraus. Seither ist Debian enorm gewachsen. Debian 9 unterstützt im Ganzen zehn Linux-Architekturen (amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el und s390x) sowie zwei kFreeBSD-Architekturen (kfreebsd-i386 und kfreebsd-amd64).

Informationen für Entwickler und Anwender über die spezifischen Portierung sind auf der Debian-Webseite Portierungen verfügbar.

4.6.3. Pakete

Es gibt zwei Typen von Debian-Paketen, nämlich source- und binary-Pakete.

Abhängig vom Format des Quellpakets wird es aus einem oder mehreren Dateien zusätzlich zur zwingend notwendigen .dsc-Datei bestehen:

• Mit Format "1.0" hat es entweder eine .tar.gz-Datei oder sowohl eine .orig.tar.gz- als auch eine .diff.gz-Datei;

• Mit Format "3.0" (quilt), hat es zwingend eine Tarball-Archivdatei von Upstream mit der Endung .orig.tar.{gz,bz2,xz}, optional mehrere .orig-Komponente.tar.{gz,bz2,xz}-Debian-Tarball-Archive;

• Mit Format "3.0" (nativ) hat es nur eine einzelne .tar.{gz,bz2,xz}-Tarball-Archivdatei.

Falls das Paket speziell für Debian entwickelt wurde und nicht außerhalb von Debian verteilt wird, gibt es dort nur eine .tar.{gz,bz2,xz}-Datei, die den Quellcode des Programms enthält, welches dann "natives" Quellpaket genannt wird. Falls ein Paket auch anderswo verteilt wird, wird in der .orig.tar.{gz,bz2,xz}-Datei der sogenannte Upstream Source Code gespeichert, das ist der Quellcode vom Upstream Maintainer (oft dem Autor der Software). In diesem Fall enthalten die Dateien .diff.gz oder debian.tar.{gz,bz2,xz} die Änderungen, die durch den Debian-Betreuer vorgenommen wurden.

Die .dsc-Datei listet alle Dateien im Quellpaket auf, zusammen mit den Prüfsummen (md5sums, sha1sums, sha256sums) und einigen zusätzlichen Informationen über das Paket (Betreuer, Version etc.).

4.6.4. Distributionen

Das im vorherigen Kapitel beschriebene Verzeichnissystem ist selbst innerhalb der distribution directories enthalten. Jede Distribution ist letztlich im Verzeichnis pool in der obersten Ebene des Debian-Archivs selbst enthalten.

Zusammenfassend gesagt hat das Debian-Archiv ein Wurzelverzeichnis auf einem FTP-Server. Auf der Spiegel-Seite ftp.us.debian.org ist beispielsweise das Debian-Archiv selbst in /debian enthalten, was ein gebräuchlicher Ort dafür ist (ein anderer ist /pub/debian).

Eine Distribution umfasst Debian-Quell- und -Binärpakete und die jeweiligen Indexdateien Sources sowie Packages, die die Kopfzeileninformationen von all diesen Paketen enthalten. Erstere werden im Verzeichnis pool/ aufbewahrt, während letztere im Verzeichnis dists/ des Archivs liegen (aus Gründen der Rückwärtskompatibilität).

4.6.4.1. Stable, testing und unstable

Es gibt immer die Distributionen mit den Namen Stable (angesiedelt in dists/stable), Testing (angesiedelt in dists/testing) und Unstable (angesiedelt in dists/unstable). Dies spiegelt den Entwicklungsprozess des Debian-Projekts wider.

In der Distribution Unstable wird aktiv entwickelt (daher wird diese Distribution manchmal auch die development distribution genannt). Jeder Debian-Entwickler kann jederzeit seine Pakete in dieser Distribution ändern. Daher ändert sich der Inhalt dieser Distribution von Tag zu Tag. Da keine besonderen Anstrengungen unternommen werden, um sicherzustellen, dass alles in dieser Distribution funktioniert, ist sie manchmal buchstäblich instabil.

Die Distribution Testing wird automatisch aus Paketen von Unstable erzeugt, falls sie bestimmte Voraussetzungen erfüllen. Diese Voraussetzungen sollten eine gute Qualität für Pakete innerhalb von Testing gewährleisten. Die Aktualisierung von Testing wird zweimal täglich lanciert, gleich nachdem die neuen Pakete installiert wurden. Siehe Die Distribution Testing.

Nach einer Entwicklungsperiode, sobald die Releasemanager diese als abgeschlossen erachten, wird die Distribution Testing eingefroren. Das bedeutet, dass die Richtlinien, die steuern, welche Pakete von Unstable nach Testing verschoben werden, verschärft werden. Pakete, die zu viele Fehler aufweisen, werden entfernt. In Testing sind außer Fehlerkorrekturen keine anderen Änderungen erlaubt. Nachdem, abhängig vom Fortschritt, einige Zeit verstrichen ist, wird die Distribution Testing sogar noch weiter eingefroren. Einzelheiten darüber, wie die Distribution Testing gehandhabt wird, werden vom Veröffentlichungs-Team auf "debian-devel-announce" publiziert. Nachdem die offenen Probleme zur Zufriedenheit des Veröffentlichungs-Teams gelöst wurden, wird die Distribtion veröffentlicht. Veröffentlichen bedeutet, dass Testing in Stable umbenannt wird und für das neue Testing eine neue Kopie erstellt wird. Das vorherige Stable wird in Oldstable umbenannt und bleibt bis zur endgültigen Archivierung dort. Bei der Archivierung wird der Inhalt nach archive.debian.org verschoben.

Der Entwicklungszyklus hängt von der Annahme ab, dass die Distribution Unstable nach einer Periode, in der sie Testing durchläuft, stabil geworden ist. Sogar wenn eine Distribution stabil geworden ist, verbleiben zwangsläufig ein paar Fehler – daher wird die stabile Distribution ab und zu aktualisiert. Diese Aktualisierungen wurden jedoch sehr gründlich getestet und werden in einem einzelnen Archiv eingeführt, um das Risiko zu vermindern, neue Fehler einzuschleppen. Sie können die geplanten Ergänzungen zu Stable im Verzeichnis proposed-updates finden. Diese Pakete in proposed-updates, die den Anforderungen entsprechen, werden periodisch in einem Stapellauf in die Stable-Distribution verschoben und die Überarbeitungsstufe der Stable-Distribution wird erhöht (z.B. "6.0" wird "6.0.1", "5.0.7" wird "5.0.8" und so weiter). Bitte sehen Sie unter Sonderfall Uploads in die Distributionen Stable und Oldstable nach, um weitere Einzelheiten zu erfahren.

Beachten Sie, dass die Entwicklung in unstable während des Freeze nicht wie gewohnt fortgesetzt werden sollte, da Pakete immer noch in unstable erstellt werden, bevor diese nach testing migriert werden. Daher sollte unstable nur Pakete enthalten die auch nach testing migrieren können müssen. Laden Sie daher Pakete nur während des Freeze nach unstable hoch, wenn Sie einen Unblock-Request anfordern möchten (oder wenn sich das Paket nicht in testing befindet).

Wenn Sie an neuen Dingen für die Zeit nach dem Freeze arbeiten laden Sie stattdessen Pakete besser nach experimental.

4.6.4.2. Weitere Informationen über die Testing-Distribution

Pakete werden üblicherweise in der Distribution Testing installiert, nachdem sie in Unstable gewissen Tests unterzogen wurden.

Lesen Sie bitte die Die Distribution Testing, um weitere Einzelheiten zu erfahren.

4.6.4.3. Experimental

Die Distribution Experimental ist eine Spezialdistribution. Sie ist keine vollständige Distribution im Sinn von Stable, Testing und Unstable. Stattdessen ist sie als temporärer Sammelpunkt für hoch experimentelle Software gedacht, bei der eine gute Chance besteht, das ganze System zu zerstören oder von Software, die sogar für die Distribution Unstable noch zu instabil ist (bei der es aber dennoch einen Grund gibt, sie zu paketieren). Bei Benutzern, die Pakete aus Experimental herunterladen und installieren, wird davon ausgegangen, dass sie ausreichend gewarnt wurden. Kurz gesagt, ist in der Distribution Experimental alles möglich.

Dies sind die Zeilen der sources.list 5 für Experimental:

deb http://deb.debian.org/debian/ experimental main
deb-src http://deb.debian.org/debian/ experimental main

Falls eine Chance besteht, dass die Software ein System schwer beschädigen könnte, ist es wahrscheinlich besser, sie in Experimental abzulegen. Zum Beispiel sollte ein experimentell komprimiertes Dateisystem wahrscheinlich nach Experimental wandern.

Jedes Mal wenn eine neue Originalversion eines Pakets vorliegt, das neue Funktionen mitbringt, aber ältere beschädigt, sollte es entweder nicht oder nach Experimental hochgeladen werden. Eine neue Beta-Version einer Software, die eine völlig unterschiedliche Konfiguration nutzt, kann nach Ermessen des Betreuers nach Experimental wandern. Falls Sie an einer inkompatiblen oder komplexen Situation bei Upgrades arbeiten, können sie Experimental auch als Sammelpunkt benutzen, damit Tester frühzeitig Zugriff darauf haben.

Trotzdem kann experimentelle Software unter machen Umständen, mit ein paar Warnungen in der Beschreibung, bewusst nach Unstable wandern, dies wird aber nicht empfohlen, da von Paketen aus Unstable erwartet wird, dass diese nach Testing und final dann nach Stable wandern kann. Sie sollten keine Angst haben Experimental zu benutzen, da es dem FTP-Master keine Probleme bereitet. Die experimentellen Pakete werden regelmäßig entfernt, wenn Sie ein Paket mit einer höheren Versionsnummer nach Unstable hochladen.

Neue Software, die das System voraussichtlich nicht beschädigt, kann direkt nach Unstable hochgeladen werden.

Eine Alternative zu Experimental ist die Benutzung Ihres persönlichen Webspaces auf people.debian.org.

4.6.5. Codenamen der Veröffentlichungen

Jede veröffentlichte Debian-Distribution hat einen Codenamen: Debian 10 wurde buster genannt, Debian 11 bullseye, Debian 12 bookworm, die nächste Debian-Veröffentlichung 13 wird trixie heißen und Debian 14 wird den Namen forky erhalten. Außerdem gibt es eine Pseudodistribution namens Sid, die die derzeitige Unstable-Distribution ist. Da Pakete von Unstable nach Testing wandern, wenn Sie stabiler werden, wird Sid selbst nie veröffentlicht. Neben dem üblichen Inhalt der Debian-Distribution enthält Sid auch Pakete für Architekturen, die noch nicht offiziell durch Debian unterstützt oder veröffentlicht werden. Es ist vorgesehen, diese Architekturen an irgendeinem zukünftigen Datum in die Hauptdistribution zu integrieren. Die Codenamen und Versionen älterer Veröffentlichungen sind auf dieser Webseite aufgeführt.

Da Debian ein offenes Entwicklungsmodell hat (d.h. jeder kann teilnehmen und der Entwicklung folgen), werden sogar die Distributionen Unstable und Testing über das Internet durch die Debian-FTP- und -HTTP-Netzwerkserver verteilt. Folglich müsste, falls das Verzeichnis, das die Kandidatenversion für die Veröffentlichung enthält, testing genannt würde, es beim Veröffentlichen der Version in stable umbenannt werden, was dazu führen würde, dass alle FTP-Spiegel die ganze Distribution erneut erhalten müssten (die ziemlich groß ist).

Wären andererseits von Anfang an die Distributionsverzeichnisse Debian-x.y genannt worden, würden die Leute denken, die Debian-Veröffentlichung x.y sei verfügbar. (Dies ist früher einmal passiert, ein CD-Verkäufer erstellte eine Debian 1.0 CD-ROM auf Bais einer pre-1.0-Entwicklerversion. Das ist der Grund, weshalb die erste offizielle Debian-Veröffentlichung 1.1 und nicht 1.0 war.)

Dadurch werden die Namen der Distributionsverzeichnisse im Archiv durch ihre Codenamen festgelegt und nicht durch ihren Veröffentlichungsstatus (z.B. "bookworm"). Diese Namen bleiben während der Entwicklungszeit und nach der Veröffentlichung erhalten. Symbolische Verweise, die einfach geändert werden können, geben die aktuell veröffentlichte stabile Distribution an. Das ist der Grund, weshalb die echten Distributionsverzeichnisse Codenamen benutzen, während symbolische Verweise für stable, testing und unstable auf die entsprechenden Veröffentlichungsverzeichnisse verweisen.

4.7. Debian-Spiegel

Für die verschiedenen Archive zum Herunterladen und die Website stehen mehrere Spiegel zur Verfügung, um die regulären Server vor zu großer Auslastung zu bewahren. Eigentlich sind einige der regulären Server nicht öffentlich zugänglich – eine erste Schicht von Spiegeln balanciert stattdessen die Last aus. Auf diese Art greifen die Anwender immer auf die Spiegel zu und sind es gewohnt, sie zu benutzen. Dies ermöglich es Debian, seine Bandbreitenanforderungen besser über mehrere Server und Netzwerke zu verteilen und vermeidet grundsätzlich, dass Benutzer übermäßig einen primären Server belasten. Beachten Sie, dass die erste Schicht von Spiegelservern so aktuell wie möglich ist, da ihre Aktualisierung durch die internen Sites ausgelöst wird (dies wird "push mirroring" genannt).

All die Informationen über Debian-Spiegel, einschließlich der verfügbaren FTP-/HTTP-Server, sind unter https://www.debian.org/mirror/ zu finden. Diese nützliche Seite enthält auch Informationen und Werkzeuge, die hilfreich sein können, falls Sie daran interessiert sind, entweder für internen oder öffentlichen Zugriff Ihren eigenen Spiegel einzurichten.

Beachten Sie, dass Spiegel generell durch Dritte betrieben werden, die ein Interesse daran haben, Debian zu helfen. Daher haben Entwickler generell keine Konten auf diesen Maschinen.

4.8. Das Incoming-System

Das Incoming-System ist dafür verantwortlich, aktualisierte Pakete zu sammeln und im Debian-Archiv zu installieren. Es besteht aus einer Zusammenstellung von Verzeichnissen und Skripten, die auf ftp-master.debian.org installiert sind.

Pakete werden von den Betreuern in ein Verzeichnis hochgeladen, das UploadQueue heißt. Dieses Verzeichnis wird alle paar Minuten durch einen Daemon gescannt, der queued genannt wird; es werden *.command-Dateien ausgeführt und verbleibende, korrekt signierte *.changes-Dateien werden zusammen mit ihren zugehörigen Dateien in das Verzeichnis unchecked verschoben. Dieses Verzeichnis ist für die meisten Entwickler unsichtbar, da FTP-Master eingeschränkt wurde. Es wird alle 15 Minuten durch das Skript dak process-upload gelesen, das die Richtigkeit der hochgeladenen Pakete und ihre kryptografischen Signaturen prüft. Falls das Paket für installationsbereit befunden wird, wird es in das Verzeichnis done verschoben. Falls dies das erste Hochladen des Pakets ist (oder es neue Binärpakete enthält), wird es in das Verzeichnis new verschoben, wo es auf die Freigabe durch die FTP-Master wartet. Falls das Paket Dateien enthält, die manuell installiert werden müssen, wird es in das Verzeichnis byhand verschoben, wo es auf die manuelle Installation durch die FTP-Master wartet. Andernfalls, falls ein Fehler aufgespürt wurde, wird das Paket abgewiesen und landet im Verzeichnis reject.

Sobald das Paket akzeptiert wurde, sendet das System dem Betreuer per E-Mail eine Bestätigung, schließt alle Fehler, die durch das Hochladen als behoben markiert wurden und die Auto-Builder können beginnen, es erneut zu kompilieren. Das Paket ist nun öffentlich unter https://incoming.debian.org/ zugänglich, bis es wirklich im Debian-Archiv installiert wird. Dies geschieht viermal täglich (und wird aus historischen Gründen "dinstall run" genannt). Das Paket wird dann aus dem Incoming-System entfernt und zusammen mit den anderen Paketen in den Pool installiert. Sobald alle anderen Aktualisierungen (Erzeugen neuer Packages- und Sources-Indexdateien zum Beispiel) durchgeführt wurden, wird ein Spezialskript aufgerufen, das alle Primärspiegel auffordert, sich selbst zu aktualisieren.

Die Archivverwaltungs-Software wird außerdem die von Ihnen hochgeladene OpenPGP signierte .changes-Datei an die entsprechenden Mailinglisten senden. Falls ein Paket veröffentlicht wird, bei dem die Distribution auf stable gesetzt ist, wird die Ankündigung an debian-changes@lists.debian.org gesandt. Falls ein Paket veröffentlicht wird, bei dem die Distribution auf unstable oder experimental gesetzt ist, wird die Ankündigung stattdessen an debian-devel-changes@lists.debian.org oder an debian-experimental-changes@lists.debian.org gesandt.

Obwohl der Zugriff auf FTP-Master eingeschränkt ist, ist eine Kopie für alle Entwickler unter mirror.ftp-master.debian.org verfügbar.

4.9. Paketinformationen

4.9.1. Im Web

Jedes Paket hat mehrere zugehörige Web-Seiten. https://packages.debian.org/Paketname zeigt jede Version des Pakets, die in verschiedenen Distributionen verfügbar ist. Jede Version verweist auf eine Seite mit Informationen, einschließlich der Paketbeschreibung, der Abhängigkeiten und der Verweise zum Herunterladen.

Die Fehlerdatenbank verfolgt Fehler für jedes Paket. Sie können die Fehler unter der URL https://bugs.debian.org/Paketname ansehen.

4.9.2. Das Hilfswerkzeug dak ls

dak ls ist Teil der Werkzeugsammlung Dak, die verfügbare Paketversionen für alle bekannten Distributionen und Architekturen auflistet. Das Werkzeug dak ist auf ftp-master.debian.org und auf dem Spiegel mirror.ftp-master.debian.org verfügbar. Es benutzt ein einziges Argument, das einem Paketnamen entspricht. Ein Beispiel erklärt es besser:

$ dak ls evince
evince     | 3.22.1-3+deb11u2 | oldstable           | source, amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
evince     | 3.22.1-3+deb11u2 | oldstable-debug     | source
evince     | 3.30.2-3+deb12u1 | stable              | source, amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
evince     | 3.30.2-3+deb12u1 | stable-debug        | source
evince     | 3.38.2-1         | testing             | source, amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x
evince     | 3.38.2-1         | unstable            | source, amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x
evince     | 3.38.2-1         | unstable-debug      | source
evince     | 40.4-1           | buildd-experimental | source, amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x
evince     | 40.4-1           | experimental        | source, amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x
evince     | 40.4-1           | experimental-debug  | source

An diesem Beispiel können Sie sehen, dass sich die Version in Unstable von der Version in Testing unterscheidet und dass dort ein rein binärer NMU des Pakets für alle Architekturen durchgeführt wurde. Jede Version des Pakets wurde auf allen Architekturen neu kompiliert.

4.10. Das Debian-Paketverfolgungssystem

Das Debian-Paketverfolgungssystem ist ein E-Mail-basiertes Werkzeug, das die Aktivität eines Quellpakets verfolgt. Sie können die gleichen E-Mails wie der Paketbetreuer erhalten, indem Sie sich einfach im PTS für das Paket einschreiben.

Das Paketverfolgungssystem hat eine Web-Schnittstelle unter https://tracker.debian.org/, die eine große Menge Informationen über jedes Quellpaket zusammenträgt. Sie zeichnet sich durch viele nützliche Verweise aus (BTS, QA-Statistiken, Kontaktinformationen, DDTP-Übersetzungsstatus, Paketerstellungsprotokolle) und sammelt noch viele weitere Informationen von verschiedenen Stellen (die 30 letzten Einträge des Änderungsprotokolls, Teststatus etc.). Es ist ein sehr nützliches Werkzeug, falls Sie wissen möchten, was bei einem speziellen Quellpaket vorgeht. Außerdem können Sie, sobald Sie sich authentifiziert haben, jedes Paket mit einem Klick abonnieren oder abbestellen.

Sie können mit einer URL wie https://tracker.debian.org/pkg/Quellpaket direkt zur Web-Seite springen, die eine spezielles Quellpaket betrifft.

Für genauere Informationen sollten Sie die Dokumentation lesen. Unter anderem wird dort erklärt, wie Sie mit ihm per E-Mail interagieren, von ihm weitergeleitete E-Mails filtern, Änderungsbenachrichtigungen vom VCS-System konfigurieren oder Features für Paketverwalter und Teams bestmöglichst ausnutzen können.

4.11. Paketübersicht des Entwicklers

Ein Webportal der QS (Qualitätssicherung) ist unter https://qa.debian.org/developer.php verfügbar. Es zeigt eine tabellarische Auflistung aller Pakete eines einzelnen Entwicklers an (einschließlich derer, bei denen eine Gemeinschaft als Mitbetreuer aufgelistet ist). Die Tabelle gibt einen guten Überblick über die Pakete des Betreuers: Anzahl der Fehler nach Schweregrad, Liste der verfügbaren Versionen in jeder Distribution, Test-Status und vieles mehr, einschließlich Verweisen zu irgendwelchen anderen nützlichen Informationen.

Es ist ein guter Tipp, regelmäßig auf seine eigenen Daten zu schauen, um keine offenen Fehler oder Zuständigkeiten für Pakete zu vergessen.

4.12. Debians FusionForge-Installation: Alioth

Alioth war ein Debian Dienst der im Juni 2018 abgelöst und danach abgeschaltet wurde. Es basierte auf einer leicht modifizierten Version der FusionForge-Software (die aus SourceForge und GForge entwickelt wurde). Diese Software bot Entwicklern Zugriff auf benutzerfreundliche Tools wie Bug-Tracker, Patch-Manager, Projekt-/Task-Manager, Datei-Hosting-Dienste, Mailinglisten, VCS-Repositorys usw.

Für viele zuvor angebotene Dienste gibt es Ersatz. Dies ist wichtig zu wissen, da es immer noch viele Hinweise auf Alioth gibt, die noch korrigiert werden müssen. Wenn Sie auf solche Referenzen stoßen, nehmen Sie sich bitte die Zeit, um zu versuchen, diese anzupassen, indem Sie beispielsweise Fehler melden oder die Referenz nach Möglichkeit selbst korrigieren.

4.13. Goodies für Debian Mitglieder

Vorteile für Debian Mitglieder sind unter https://wiki.debian.org/MemberBenefits dokumentiert.

5. Pakete verwalten

Dieses Kapitel enthält Informationen, die sich auf das Erstellen, Hochladen, Verwalten und Portieren von Paketen beziehen.

5.1. Neue Pakete

Falls Sie ein neues Paket für die Debian-Distribution erstellen möchten, sollten Sie zuerst die Liste der Arbeit-bedürfenden und voraussichtlichen Pakete (WNPP) prüfen. Die Prüfung der WNPP-Liste stellt sicher, dass nicht bereits jemand an der Paketierung dieser Software arbeitet und kein doppelter Aufwand betrieben wird. Weitere Informationen finden Sie auf den WNPP-Web-Seiten.

Ausgehend von der Annahme, dass noch niemand an Ihrem zukünftigen Paket arbeitet, müssen Sie einen Fehlerbericht (Fehler berichten) gegen das Pseudopaket wnpp einreichen, in dem Sie Ihr Vorhaben vorstellen. Der Fehlerbericht muss mindestens eine Beschreibung des neuen Pakets enthalten (sodass andere es überprüfen können), die Lizenz angeben die dem Paket zugedacht werden soll, sowie die derzeitige URL, von der es heruntergeladen werden kann.

Sie sollten den Betreff des Fehlers auf ITP:Paketname--kurze Beschreibung setzen, wobei Sie Paketname durch den Namen Ihres Pakets ersetzen. Der Schweregrad des Fehlerberichts muss auf wishlist gesetzt werden. Bitte senden Sie mit der Kopfzeile X-Debbugs-CC eine Kopie an debian-devel@lists.debian.org (benutzen Sie nicht CC:, da in diesem Fall der Betreff der Nachricht die Fehlernummer nicht angibt). Falls Sie so viele (mehr als zehn) neue Pakete paketieren, dass die Benachrichtigung auf der Liste als störend empfunden würde, senden Sie stattdessen nach dem Einreichen des Fehlers eine Zusammenfassung an die Liste "debian-devel". Dies wird andere Entwickler über die bevorstehenden Pakete informieren und eine Überprüfung Ihrer Beschreibung und Ihres Paketnamens ermöglichen.

Bitte fügen Sie im Änderungsprotokoll des neuen Pakets den Eintrag Closes: #nnnnn hinzu, um den Fehlerbericht automatisch zu schließen, sobald das neue Paket im Archiv installiert wird (siehe Wann Fehler durch neue Uploads geschlossen werden).

Falls Sie der Ansicht sind Ihr Paket bedürfe einiger Erklärungen für die Administratoren der Paketwarteschlange NEW, so fügen Sie diese dem Änderungsprotokoll hinzu, senden Sie die E-Mail die Sie als Betreuer nach dem Upload zurückbekommen haben an ftpmaster@debian.org oder antworten Sie auf die ablehnende E-Mail für den Fall, dass Sie bereits erneut hochladen.

Wenn sicherheitskritische Fehler geschlossen werden, fügen Sie die CVE-Nummern sowie Closes: #nnnnn bei. Dies ist nützlich zur Verfolgung von Schwachstellen durch das Sicherheits-Team. Falls etwas hochgeladen wird, bevor die ID der Sicherheitsankündigung bekannt ist, sollte beim nächsten Upload der historische Änderungsprotokolleintrag geändert werden. Bitte fügen Sie sogar in diesem Fall dem Original-Änderungsprotokolleintrag alle verfügbaren Hinweise auf Hintergrundinformationen hinzu.

Es gibt eine Vielzahl von Gründen weshalb Paketbetreuer um die Ankündigung ihrer Absichten gebeten werden:

• Es hilft dem (möglicherweise neuen) Betreuer, die Erfahrung der Leute auf der Liste anzuzapfen und teilt ihm mit, ob jemand anderes bereits daran arbeitet.

• Es zeigt anderen Leuten, die darüber nachdenken am Paket zu arbeiten, dass es bereits einen Freiwilligen gibt, so dass der Aufwand verteilt werden kann.

• Es sagt den übrigen Betreuern mehr über das Paket, als nur aus Beschreibungszeile erkennbar und der übliche Eintrag im Änderungsprotokoll "Initial release", der an debian-devel-changes@lists.debian.org gesandt wird.

• Es ist hilfreich für Leute, die die Veröffentlichung Unstable für die tägliche Arbeit benutzen (und die die vorderste Frontlinie von Testern bilden). Diese Leute sollten ermutigt werden.

• Die Ankündigungen geben Betreuern und anderen interessierten Parteien ein besseres Gefühl dafür, was gerade geschieht und was im Projekt neu ist.

Bitte lesen Sie unter https://ftp-master.debian.org/REJECT-FAQ.html die häufigsten Gründe für die Ablehnung neuer Pakete.

5.2. Änderungen im Paket aufzeichnen

Von Ihnen vorgenommene Änderungen müssen in debian/changelog in einer Form aufgezeichnet werden, so dass andere Personen die Änderungen nachvollziehen uns verstehen können. Diese Änderungen sollten eine kurzgefasste Beschreibung bereitstellen, was geändert wurde, warum (falls dies zweifelhaft ist) und vermerken, ob irgendwelche Fehler geschlossen wurden. Sie zeichnen außerdem auf, wenn das Paket vervollständigt wurde. Diese Datei wird in /usr/share/doc/Paket/changelog.Debian.gz (oder /usr/share/doc/Paket/changelog.gz für native Pakete) installiert.

Die Datei debian/changelog hat eine bestimmte Struktur mit einer Anzahl unterschiedlicher Felder. Ein bedeutendes Feld, die distribution, wird in Eine Distribution auswählen beschrieben. Weitere Informationen über die Struktur dieser Datei sind im Abschnitt debian/changelog der Debian-Richtlinien zu finden.

Wenn das Paket im Archiv installiert ist, können Einträge im Änderungsprotokoll benutzt werden, um Debian-Fehler automatisch zu schließen. Siehe Wann Fehler durch neue Uploads geschlossen werden.

Es ist üblich, dass der Änderungsprotokolleintrag eines Pakets, der eine neue Originalversion der Software enthält, wie folgt aussieht:

* New upstream release.

Es gibt Werkzeuge, die Ihnen helfen, Einträge zu erstellen und das changelog zur Veröffentlichung fertigzustellen – siehe devscripts und dpkg-dev-el.

Siehe auch Optimale Vorgehensweisen für debian/changelog.

5.3. Das Paket testen

Bevor Sie Ihr Paket hochladen, sollten Sie es grundlegenden Tests unterziehen. Zumindest sollten Sie die folgenden Dinge ausprobieren (Sie sollten eine ältere Version des gleichen Debian-Pakets zur Hand haben):

• Führen Sie für das Paket lintian aus. Sie können lintian wie folgt ausführen: lintian -vPaket-Version.changes. Falls Sie die von lintian erzeugte Ausgabe nicht verstehen, versuchen Sie den Schalter -i hinzuzufügen. Er veranlasst lintian eine viel detailliertere Beschreibung des Problems auszugeben.

  Normalerweise sollte ein Paket nicht hochgeladen werden, wenn es lintian-Fehler (diese beginnen mit E) verursacht.

  Weitere Informationen über lintian finden Sie unter lintian.

• Führen Sie wahlweise debdiff (siehe debdiff) aus, um Änderungen von einer älteren Version zu analysieren, falls es eine solche gibt.

• Installieren Sie das Paket und prüfen die korrekte Funktion dessen in einem tagesaktuellem Unstable System.

• Aktualisieren Sie das Paket von einer vorherigen Version auf Ihre neu erstellte Version.

• Entfernen Sie das Paket und installieren Sie es erneut.

• Die Installation, eine Aktualisierung oder auch ein komplettes Entfernen des Paketes können manuell oder auch durch das piuparts Werkzeug getestet werden.

• Kopieren Sie das Quellpaket in ein anderes Verzeichnis und versuchen Sie es zu entpacken und neu zu erstellen. Dies testet, ob das Paket bestehende Dateien von außerhalb des Tarballs benötigt oder ob es auf Benutzerrechten beruht, die in den Dateien konserviert sind, die innerhalb der .diff.gz-Datei mitgeliefert wurden.

5.4. Layout des Quellpakets

Es gibt zwei Typen von Debian-Quellpaketen:

• Die sogenannten native-Pakete, bei denen es keine Unterschiede zwischen dem Originalquellcode und den auf Debian angewandten Patches gibt.

• Die (häufigeren) Pakete, bei denen der originale Quellcode-Tarball mit einer anderen Datei mitgeliefert wird, die die von Debian vorgenommenen Änderungen enthält.

Bei nativen Paketen enthält der Quell-Tarball eine Steuerungsdatei für Debian-Quellen (.dsc) und einen Quell-Tarball (.tar.{gz,bz2,xz}). Ein Quellpaket eines nicht nativen Paketes enthält eine Steuerungsdatei für Debian-Quellen, den Original-Quellcode-Tarball (.orig.tar.{gz,bz2,xz}) und die Debian-Änderungen (.diff.gz für das Quellformat "1.0" oder .debian.tar.{gz,bz2,xz} für das Quellformat "3.0 (quilt)").

Mit dem Quellformat "1.0" wurde zur Zeit des Erstellens durch dpkg-source festgelegt, ob ein Paket nativ ist oder nicht. Heutzutage wird empfohlen, das gewünschte Quellformat explizit durch Angabe von "3.0 (quilt)" oder "3.0 (native)" in debian/source/format festzulegen. Der Rest dieses Abschnitts bezieht sich auf nicht native Pakete.

Anfangs, wenn eine Version hochgeladen wird, die einer bestimmten Version des Ursprungsquellcodes entspricht, muss die Original-Tar-Quelldatei hochgeladen und in die .changes-Datei eingefügt werden. Nachfolgend sollte eben diese Tar-Datei benutzt werden, um neue .diff- und .dsc-Dateien zu erstellen ohne die Notwendigkeit, diese erneut hochzuladen.

Standardmäßig werden dpkg-genchanges und dpkg-buildpackage die Original-Tar-Quelldatei nur dann einbeziehen, falls der aktuelle Änderungsprotokolleintrag eine andere Originalversion des vorhergehenden Eintrags hat. Dieses Verhalten kann durch die Benutzung der Option -sa geändert werden, um es immer einzubeziehen oder -sd, um es immer wegzulassen.

Falls im Upload kein Originalquellcode enthalten ist, muss die Original-Tar-Quelldatei, die von dpkg-source benutzt wurde, um die .dsc-Datei und die hochzuladene Diff-Datei zu erzeugen, Byte für Byte identisch mit der sein, die bereits im Archiv ist.

Bitte beachten Sie, dass in nicht nativen Paketen Zugriffsrechte von Dateien, die nicht in den *.orig.tar.{gz,bz2,xz}-Dateien enthalten sind, nicht aufbewahrt werden, da das Diff die Dateizugriffsrechte nicht im Patch speichert. Wenn Sie jedoch das Format "3.0 (quilt)" benutzen, werden Zugriffsrechte von Dateien innerhalb des debian-Verzeichnisses aufbewahrt, da sie in einem Tar-Archiv gespeichert werden.

5.5. Eine Distribution auswählen

Bei jedem Upload muss angegeben werden, für welche Distribution das Paket gedacht ist. Der Prozess der Paketerstellung extrahiert diese Information aus der ersten Zeile der Datei debian/changelog und platziert sie im Feld Distribution der .changes-Datei.

Normalerweise werden Pakete nach Unstable hochgeladen. Beim Hochladen nach Unstable oder Experimental sollte diese Suite-Namen im Änderungsprotokolleintrag verwendet werden. Beim Hochladen für andere unterstützte Suites sollten die Suite-Codenamen benutzt werden, um Mehrdeutigkeiten zu vermeiden.

Außerdem gibt es auch noch andere mögliche Distributionen: codename-security, aber lesen Sie Handhabung von sicherheitsrelevanten Fehlern, um weitere Informationen darüber zu erhalten.

Es ist nicht möglich ein Paket gleichzeitig in mehrere Distributionen hochzuladen.

5.5.1. Sonderfall Uploads in die Distributionen Stable und Oldstable

Hochladen nach Stable bedeutet, dass das Paket in die Warteschlange proposed-updates-new übertragen wird, damit es von den Veröffentlichungsverwaltern überprüft werden kann. Falls es zugelassen wird, wird es in das Verzeichnis stable-proposed-updates des Debian-Archivs installiert. Von dort wird es zum nächsten Veröffentlichungszeitpunkt in Stable eingefügt.

Uploads in eine unterstützte Stable Version sollten den Suite-Namen im Änderungslog enthalten, also zum Beispiel. bookworm oder bullseye. Üblicherweise sollten Sie reportbug benutzen um einen Bugreport gegen das Pseudopaket release.debian.org zu erstellen, und in diesem eine Ausgabe von debdiff (basierend von der aktuellen Paketversion) gegen die momentan aktuelle Version in Stable anhängen wenn Sie ein Paket in einer der aktuellen Stable Veröffentlichungen aktualisieren wollen. Ebenso sollten Sie innerhalb dieses Bugreports begründen warum Sie die Version in Stable aktualisieren wollen. Sofern es zugehörige andere Fehlernummern gibt, die in Bezug zur vorbereiteten neuen Version für Stable stehen, geben Sie diese mit an. Die Release-Manager entscheiden über das weitere Vorgehen und werden Ihnen weitere Information zukommen lassen.

Wenn Sie sicher sind, dass der Upload ohne Änderungen akzeptiert werden wird, können Sie ihn gleichzeitig mit dem Einreichen des Fehlerreports gegen release.debian.org hochladen. Wenn Sie mit dem Prozess noch nicht vertraut sind, empfehlen wir Ihnen, vor dem Hochladen eine Genehmigung einzuholen, damit Sie sehen können, ob Ihre Erwartungen mit denen des Veröffentlichungsteam übereinstimmen.

In beiden Fällen muss ein Fehlerreport zur Nachverfolgung vorliegen, und Ihr Upload muss den festgelegten Akzeptanzkriterien vom Veröffentlichungsteam entsprechen. Diese Kriterien sollen dazu beitragen, dass der Prozess so reibungslos und frustrationsfrei wie möglich verläuft.

• Der Fehler, den Sie in Stable beheben möchten, muss bereits in Unstable behoben sein (und das Paket mit der korrigierten Version darf nicht in NEW oder der Delayed-Queue liegen).

• Der Fehlerreport muss die Dringlichkeit "Important" oder höher besitzen.

• Die Metadaten des Fehlerreports - im Speziellen die betroffenen Versionen - müssen aktuell sein.

• Fehlerbehebungen müssen so klein als möglich aber auch relevant sein und und einen ausreichend detaillierten Änderungsprotokolleintrag enthalten.

• Ein Quell-Debdiff der vorgeschlagenen Änderung muss in Ihrer Anfrage enthalten sein (nicht nur die nackten Patches oder "Ein Debdiff kann unter $URL gefunden werden").

• Das vorgeschlagene Paket muss eine korrekte Versionsnummer haben (z. B. ...+deb12u1 für Bookworm oder +deb10u1 für Bullseye) und Sie sollten erklären können wie es getestet worden ist. Die Versionsnummer wird in der Debian Policy definiert: https://www.debian.org/doc/debian-policy/ch-controlfields.html#special-version-conventions

• Das Update muss in einer Stable Umgebung oder Chroot erstellt worden sein (oder Oldstable wenn dies die Zielveröffentlichung ist).

• Korrekturen für Sicherheitsprobleme sollten mit dem Sicherheitsteam abgestimmt werden, es sei denn, Sie haben ausdrücklich angegeben, dass das Sicherheitsteam keinen DSA für den Fehler erstellt hat (z. B. über einen "no-dsa"-Marker im Debian Security Tracker).

• Sie sollten release.debian.org Fehler in debian/changelog nicht selber schließen. Die Fehler werden vom Release Team geschlossen, wenn das Paket die jeweilige Zwischenveröffentlichung erreicht hat.

Es wird empfohlen, reportbug zu verwenden, da dies die Erstellung von Fehlern mit korrekten Metadaten erleichtert. Das Veröffentlichungsteam verwendet in großem Umfang Usertags, um Anforderungen zu sortieren und zu verwalten. Falsch gekennzeichnete Berichte können länger dauern, bis sie bemerkt und verarbeitet werden.

Uploads nach Oldstable-Distributionen sind möglich, solange diese nicht archiviert sind. Es gelten die gleichen Regeln wie für Stable.

Früher wurden Uploads nach Stable benutzt, um auch Sicherheitsprobleme anzugehen. Diese Praxis ist jedoch missbilligt, da Uploads für Debian-Sicherheitsankündigungen (DSAs) automatisch in das entsprechende Archiv proposed-updates kopiert werden, wenn die Ankündigung veröffentlicht wird. Weitere detailliertere Informationen über die Handhabung von Sicherheitsproblemen finden Sie unter Handhabung von sicherheitsrelevanten Fehlern. Falls das Sicherheits-Team das Problem als zu harmlos erachtet, um es durch ein DSA zu beheben, sind die Veröffentlichungsverwalter normalerweise trotzdem bereit, Ihre Fehlerbehebung bei einem regulären Upload nach Stable einzufügen.

5.5.2. Sonderfall stable-updates Suite

Manchmal entscheiden die Veröffentlichungsmanager, dass ein Update für Stable den Benutzern früher als zur nächsten geplanten Point-Release zur Verfügung gestellt werden soll. In solchen Fällen können Sie das Update in die Suite stable-updates kopieren, die Verwendung dieser Suite wird standardmäßig vom Installationsprogramm aktiviert.

Der Prozess hierzu ist der Gleiche wie in Sonderfall Uploads in die Distributionen Stable und Oldstable. Wenn Sie der Meinung sind, dass Ihr Pakte über stable-updates veröffentlicht werden soll, erwähnen Sie dies in Ihrer Anfrage an das Veröffentlichungsteam. Beispiele für Umstände, unter denen sich der Upload für eine solche Behandlung qualifizieren kann, sind:

• Das Update ist dringend jedoch nicht sicherheitsrelevant. Beispiele hierfür sind Pakete, die durch den Zeitfluss unterbrochen wurden (vgl. spamassassin und das Problem des Jahres 2010) und Korrekturen für Fehler, die durch Point-Releases verursacht wurden (z.B. Regressions). Sicherheitsupdates werden weiterhin unabhängig hiervon durch das Sicherheitsarchiv getätigt.

• Das fragliche Paket ist einen Datenpaket und muss zeitnah aktualisiert werden (z.B. tzdata).

• Korrekturen an mehrschichtigen Paketen, die durch externe Änderungen disfunktional wurden (z. B. Tools zum Herunterladen von Videos und tor).

• Pakete, die aktuell sein müssen, um nützlich zu sein (z. B. clamav).

• Uploads nach Stable-updates sollten wie gewohnt den Namen der Suite im Changelog enthalten, z.B. Bookworm.

Sobald der Upload für proposed-updates akzeptiert wurde und zur Veröffentlichung bereit steht, kopieren die Veröffentlichungsmanager diesen in die Suite stable-updates und geben über die Mailingliste debian-stable-announce ein Stable Update Announcement (SUA) heraus.

Alle Aktualisierungen in stable-updates werden auch in der nächsten Point-Release von Stable enthalten sein.

5.5.3. Sonderfall Uploads nach testing/testing-proposed-updates

Bitte lesen Sie die Informationen im Direkte Aktualisierungen für Testing, um weitere Einzelheiten zu erfahren.

5.6. Ein Paket hochladen

5.6.1. Source und Binär Uploads

Jeder Upload in Debian beinhaltet eine signierte Datei .changes in der die angeforderten Änderungen am Archive beschrieben sind, plus ebenfalls das Source und Binärpaket welche durch die Datei .changes referenziert werden.

Wenn möglich sollte die Version des Uploads für das Paket ein source-only changes Datei sein. Diese sind typischerweise nach dem Muster *_source.changes benannt und referenzieren das Source Paket, aber nicht binäre .deb or .udeb Pakete. Alle entsprechenden architekturabhängigen und architekturunabhängigen Binärpakete für alle Architekturen werden von den Build-Daemons automatisch in einer kontrollierten und vorhersehbaren Umgebung erstellt (Siehe wanna-build für mehr Details). Aber, es gibt natürlich einige Situationen wo dies in der Form so nicht möglich ist.

Das erste Hochladen eines neuen Source Paketes (see Neue Pakete) muss die Binärpakte enthalten. Diese werden im Review Prozess der Debian-Archivbetreuer benötigt bevor diese zu Debian hinzugefügt werden können.

Wenn neue Binärpakte zu vorhandenen Source Paketen hinzugefügt werden dann muss das erste Hochladen was die neuen Binärpakte in debian/control enthält ebenfalls die Binärpkate enthalten. Der Grund hierfür ist wieder der Gleiche wie beim Einführen eines neuen Source Paketes, der Review Prozess der Debian-Archivbetreuer erfordert dies. Wünschenswert ist das Benutzen der Suite experimental für derartige Uploads.

Uploads, die zur Überprüfung in anderen Queues durchgeführt werden, zum Beispiel für Pakete die zu den Suites *-backports hinzugefügt werden sollen, können es ebenfalls erfordern, dass Binärpakte hochgeladen werden müssen.

Die Buildd Daemons starten den Bau aller Pakete aus main` oder contrib sofern die hierzu nötigen Paketabhängigkeiten erfüllt werden können. Pakete in non-free und non-free-firmware werden nur automatisch gebaut sofern diese Pakete als geeignet markiert worden sind für das automatische Bauen (Siehe Unfreie Pakete als automatisch erstellbar kennzeichnen).

Die Build Daemons installieren nur zum Bau benötigte Pakete aus dem Bereich des main Archivs. Dies bedeutet, wenn ein Source Paket abhängige Pakete zum Bauen aus den Archivbereichen contrib, non-free oder non-free-firmware benötigt, dann müssen Uploads dieses Pakets vorgefertigte Binärpakete für alle unterstützen Architekturen enthalten. Definitionsbedingt kann dies nur der Fall sein wenn das Source Paket selbst in einem der Archivbereiche contrib, non-free oder non-free-firmware liegt.

Beim Bootstrapping einer neuen Architektur, oder einer neuen Version eines Paketes mit zirkularen Abhängigkeiten (wie z.B. ein Self Hosting Compiler) ist es auch manchmal notwendig dass das Hochladen mit den erstellten Binärpaketen erfolgen muss.

Binärpakete im main Archiv, die nicht durch die offiziellen Debian Build Daemons erstellt worden sind, werden nicht, wo sonst üblich, automatisch von unstable nach testing migrieren. Dadurch muss nach ein Upload, der nur Binärpakete enthalten hat, ein weiteres Hochladen als source-only Upload erfolgen nachdem der vorherige Upload mit den Binärpaketen akzeptiert worden ist. Diese Bestimmung gilt nicht für Pakete aus contrib, non-free oder non-free-firmware.

5.6.2. Hochladen nach ftp-master

Um ein Paket hochzuladen, sollten Sie die Dateien (einschließlich der signierten Änderungen an der dsc-Datei) mit anonymem FTP nach ftp.upload.debian.org in das Verzeichnis /pub/UploadQueue/ hochladen. Damit die Dateien dort verarbeitet werden, müssen sie mit einem Schlüssel aus dem Debian-Entwickler-Schlüsselbund signiert sein (siehe https://wiki.debian.org/DebianMaintainer).

Bitte beachten Sie, dass Sie die Datei "changes" zuletzt übertragen sollten. Andernfalls könnte Ihr Upload abgelehnt werden, da die Archivverwaltungs-Software die "changes"-Datei auswertet und feststellt, dass nicht alle Dateien hochgeladen wurden.

Vielleicht finden Sie auch die Debian-Pakete dupload oder dput nützlich, um Pakete hochzuladen. Diese praktischen Programme helfen den Prozess des Hochladens von Paketen nach Debian zu automatisieren.

Um Pakete aus der Upload Queue zu entfernen sehen Sie sich bitte ftp://ftp.upload.debian.org/pub/UploadQueue/README und das Debian-Paket dcut an.

Sie sollten aber auch über den Status Ihres Paket in Testing nachdenken bevor Sie eine neue Version nach Unstable laden. Wenn Sie eine Version in Unstable haben die auf die Migration nach Testing wartet, ist es im Allgemeinen eine gute Idee, diese zunächst migrieren zu lassen, bevor Sie eine andere neue Version hochladen. Sie sollten auch Das Debian-Paketverfolgungssystem auf Warnungen überprüfen, um Uploads zu vermeiden, die laufende Übergänge stören.

5.6.3. Verzögerte Uploads

Manchmal ist es nützlich, ein Paket sofort hochzuladen, aber gleichzeitig festzulegen, dass dieses Paket das Archiv erst ein paar Tage später erreicht. Sie könnten, wenn Sie beispielsweise einen Non-Maintainer Uploads (NMUs) vorbereiten, dem Betreuer ein paar Tage Zeit geben wollen, damit er reagieren kann.

Bei einem Upload des Pakets in das Verzögerungsverzeichnis wird es in der deferred uploads queue gehalten. Wenn die angegebene Wartezeit vorüber ist, wird das Paket zur Verarbeitung in das reguläre Eingangsverzeichnis verschoben. Dies wird erledigt durch automatisches Hochladen nach ftp.upload.debian.org in das Upload-Verzeichnis DELAYED/X-day (X ist eine Zahl zwischen 0 und 15). 0-day wird mehrmals täglich nach ftp.upload.debian.org hochgeladen.

Mit dput können Sie den Parameter --delayed VERZÖGERUNG benutzen, um das Paket in eine der Warteschlangen einzureihen.

5.6.4. Sicherheits-Uploads

Laden Sie KEIN Paket in die Sicherheits-Upload-Warteschlange (auf security-master.debian.org hoch, ohne vorher eine Erlaubnis vom Sicherheits-Team erhalten zu haben. Falls das Paket nicht exakt den Anforderungen des Teams entspricht, wird es viele Probleme und Verzögerungen in der Behandlung des unerwünschten Uploads verursachen. Um Einzelheiten zu erhalten, lesen Sie Handhabung von sicherheitsrelevanten Fehlern.

5.6.5. Andere Upload-Warteschlangen

Es gibt in Europa eine alternative Upload-Warteschlange unter ftp://ftp.eu.upload.debian.org/pub/UploadQueue/. Sie arbeitet auf die gleiche Weise wie ftp.upload.debian.org, sollte aber für europäische Entwickler schneller sein.

Pakete können auch per SSH nach ssh.upload.debian.org hochgeladen werden. Dateien sollten in /srv/upload.debian.org/UploadQueue abgelegt werden. Diese Warteschlange unterstützt keine Verzögerte Uploads.

5.6.6. Benachrichtigungen

Die Debian-Archivbetreuer sind für die Behandlung der Paket-Uploads verantwortlich. Zum größten Teil werden Uploads automatisch täglich durch das Archiv-Verwaltungswerkzeug dak process-upload verarbeitet. Im Besonderen werden Aktualisierungen zu existierenden Paketen in der Distribution Unstable automatisch eingepflegt. In anderen Fällen, insbesondere bei neuen Paketen, wird das hochgeladene Paket manuell in die Distribution platziert. Wenn Uploads manuell behandelt werden, kann es einige Zeit dauern, bis die Änderung im Archiv erscheint. Bitte haben Sie Geduld.

Auf jeden Fall werden Sie eine E-Mail-Benachrichtigung erhalten, die anzeigt, dass das Paket dem Archiv hinzugefügt wurde und welche Fehler durch den Upload geschlossen werden. Bitte lesen Sie diese Benachrichtigung sorgfältig und prüfen Sie, ob irgendwelche Fehler, die Sie schließen wollten, nicht berücksichtigt wurden.

Die Installationsbenachrichtigung enthält außerdem die Information, in welchen Abschnitt das Paket eingefügt wird. Falls es dort eine Ungleichheit gibt, werden Sie eine separate E-Mail-Benachrichtigung darüber erhalten. Lesen Sie das Folgende.

Beachten Sie, dass, falls Sie mittels Warteschlangen hochladen, die Warteschlangen-Daemon-Software Ihnen auch per E-Mail Benachrichtigungen sendet.

Beachten Sie außerdem, dass neue Uploads im IRC-Kanäle-Kanal #debian-devel-changes publiziert werden. Falls der Upload ohne Benachrichtigung fehlgeschlagen ist, kann es sein, dass Ihr Paket keine gültige Signatur hatte. In diesem Fall finden Sie weitere Erläuterungen in ssh.upload.debian.org:/srv/upload.debian.org/queued/run/log.

5.7. Angabe des Paketbereichs, des Unterbereichs und der Priorität

Die Felder Section und Priority der Datei debian/control geben weder an, wo die Datei im Archiv tatsächlich platziert wird noch deren Priorität. Um die gesamte Integrität des Archivs zu wahren, haben die Archivbetreuer die Kontrolle über diese Felder. Die Werte in der Datei debian/control sind letztlich nur Hinweise.

Die Archivbetreuer behalten den Überblick über die vorschriftsmäßigen Bereiche und Prioritäten für Pakete im override file. Falls es dort einen Unterschied zwischen dem override file und den Paketfeldern, die in debian/control angezeigt werden, gibt, werden Sie eine E-Mail-Benachrichtigung über die Abweichung erhalten, wenn das Paket in das Archiv installiert wird. Sie können entweder Ihre debian/control-Datei für Ihren nächsten Upload ändern oder eine Änderung am override file vorschlagen.

Um den tatsächlichen Bereich abzuändern, in den Ihr Paket abgelegt wird, müssen Sie zuerst sicherstellen, dass die Datei debian/control in Ihrem Paket fehlerfrei ist. Als nächstes versenden Sie einen Fehlerbericht gegen ftp.debian.org mit der Bitte, den Bereich oder die Priorität für Ihr Paket von dem alten auf den neuen Bereich oder die neue Priorität zu ändern. Benutzen Sie einen Betreff wie override: PACKAGE1:section/priority, [...], PACKAGEX:section/priority und fügen Sie die Begründung der Änderung in den Nachrichtentext des Fehlerberichts ein.

Weitere Informationen über override files finden Sie unter dpkg-scanpackages 1 und https://www.debian.org/Bugs/Developer#maintincorrect.

Beachten Sie, dass das Feld Section sowohl den Bereich als auch den Unterbereich beschreibt, die in Bereiche erläutert werden. Falls der Bereich "main" ist, sollte er weggelassen werden. Die Liste der erlaubten Unterbereiche finden Sie unter https://www.debian.org/doc/debian-policy/ch-archive.html#s-subsections.

5.8. Fehlerbehandlung

Jeder Entwickler muss in der Lage sein, mit der Debian-Fehlerdatenbank zu arbeiten. Dies umfasst das Wissen, wie Fehlerberichte richtig eingeordnet werden (siehe Fehler berichten), wie sie aktualisiert und neu geordnet werden und wie sie verarbeitet und geschlossen werden.

Die Funktionen des Fehlerverfolgungssystems sind in unter Fehlerverwaltungssystem für Paket-Betreuer beschrieben. Dies umfasst das Schließen von Fehlern, Followup-Nachrichten, Zuweisen von Schweregraden, Markieren von Fehlern als weitergeleitet und andere Themen.

Operationen wie das erneute Zuweisen von Fehlern an andere Pakete, das Zusammenführen separater Fehlerberichte zum gleichen Thema oder das Wiedereröffnen von Fehlern, wenn diese voreilig geschlossen wurden, werden vom sogenannten Steuermailserver verarbeitet. Alle Befehle, die auf diesem Server verfügbar sind, werden in der Einführung in den E-Mail-Server für die Kontrolle und Manipulation beschrieben.

5.8.1. Fehlerüberwachung

Falls Sie ein guter Paketbetreuer sein möchten, sollten Sie regelmäßig die Debian-Fehlerdatenbank (BTS) für Ihre Pakete überprüfen. Das BTS enthält alle offenen Fehler Ihrer Pakete. Sie können sie prüfen, indem Sie diese Seite durchstöbern: https://bugs.debian.org/nickname@debian.org.

Paketbetreuer interagieren mit dem BTS über E-Mail-Adressen auf bugs.debian.org. Dokumentationen über verfügbare Befehle können Sie unter https://www.debian.org/Bugs/ finden oder, falls Sie das Paket doc-debian installiert haben, schauen Sie in die lokalen Dateien /usr/share/doc/debian/bug-*.

Einige finden es nützlich, regelmäßig Berichte über offene Fehler zu erhalten. Sie können einen Cron-Job wie den folgenden hinzufügen, falls Sie wöchentlich eine E-Mail erhalten möchten, die alle Fehler Ihrer Pakete zusammenfasst:

# ask for weekly reports of bugs in my packages
0 17 * * fri   echo "index maint address" | mail request@bugs.debian.org

Ersetzen Sie address durch Ihre offizielle Debian-Betreueradresse.

5.8.2. Auf Fehler antworten

Stellen Sie bei der Reaktion auf Fehler sicher, dass alle Diskussionen über Fehler an den ursprünglichen Übermittler des Fehlers aber auch an den Fehlerreport selbst und (wenn Sie nicht der Betreuer des Pakets sind) den Betreuer gesendet werden. Wenn Sie eine E-Mail an 123@bugs.debian.org senden, wird die E-Mail an den Betreuer des Pakets gesendet und Ihre E-Mail mit im Fehlerprotokoll aufgezeichnet. Wenn Sie sich nicht an die E-Mail-Adresse des Absenders erinnern, können Sie mit 123-submitter@bugs.debian.org auch den Absender des Fehlers kontaktieren. Letztere Adresse zeichnet auch die E-Mail-Korrespondenz mit im Fehlerprotokoll auf. Wenn Sie also der Betreuer des betreffenden Pakets sind, reicht es aus, die Antwort an 123-submitter@bugs.debian.org zu senden. Andernfalls sollten Sie 123@bugs.debian.org benutzen, damit Sie auch den Paketbetreuer erreichen.

Falls Sie einen Fehlerbericht erhalten, der FTBFS erwähnt, so bedeutet dies "Fails to build from source" (Kann nicht aus dem Quellcode erstellt werden). Portierer benutzen diese Abkürzung öfter.

Sobald Sie einen Fehlerbericht erledigt (z.B. den Fehler behoben) haben, markieren Sie ihn als done (dies schließt ihn), indem Sie eine Erklärung an 123-done@bugs.debian.org senden. Falls Sie einen Fehler durch Ändern und Hochladen des Pakets schließen, können Sie das Schließen von Fehlern, wie in Wann Fehler durch neue Uploads geschlossen werden beschrieben, automatisieren.

Sie sollten Fehler niemals durch Senden des Befehls close an control@bugs.debian.org schließen. Falls Sie dies tun, wird der ursprüngliche Absender keine Informationen darüber erhalten, warum der Fehler geschlossen wurde.

5.8.3. Verwaltung von Fehlerberichten

Als Paketbetreuer werden Sie öfter Fehler in anderen Paketen finden oder Fehlerberichte gegen Ihre Pakete erhalten, die tatsächlich Fehler in anderen Paketen sind. Die Funktionen der Fehlerdatenbank werden in den Informationen über das Fehlerverwaltungssystem für Paket-Betreuer beschrieben. Operationen wie erneutes Zuweisen, Zusammenführen und Markieren von Fehlerberichten werden in der Einführung in den E-Mail-Server für die Kontrolle und Manipulation beschrieben. Dieser Abschnitt enthält einige Regeln für die Verwaltung Ihrer eigenen Fehler, die auf der gesammelten Erfahrung der Debian-Entwickler basieren.

Fehler für Probleme einzureichen, die Sie in anderen Paketen finden, ist eine der bürgerlichen Pflichten des Betreuerdaseins. Einzelheiten finden Sie unter Fehler berichten. Es ist jedoch wichtiger, die Fehler in den eigenen Paketen zu behandeln.

Hier ist eine kurze Liste der Schritte, denen Sie zu Handhabung eines Fehlerberichts folgen können:

1. Entscheiden Sie, ob der Bericht einem echten Fehler entspricht oder nicht. Manchmal rufen Anwender ein Programm nur auf die falsche Art auf, da Sie die Dokumentation nicht gelesen haben. Falls Sie dies diagnostizieren, schließen Sie den Fehler einfach und stellen Sie Informationen bereit, damit der Anwender sein Problem lösen kann (verweisen Sie auf die gute Dokumentation und so weiter). Falls der gleiche Bericht immer wieder kommt, sollten Sie sich fragen, ob die Dokumentation ausreicht oder ob das Programm den falschen Gebrauch feststellen kann, um eine aussagekräftige Fehlermeldung auszugeben. Dies ist ein Thema, das Sie mit dem Originalautor angehen sollten.

   Wenn der Fehlerübermittler mit Ihrer Entscheidung, den Fehler zu schließen nicht einverstanden ist, wird er möglicherweise erneut geöffnet, bis Sie eine Vereinbarung zur Behandlung des Fehlers gefunden haben. Wenn Sie keine Übereinkunft finden, möchten Sie möglicherweise den Fehler "wontfix" markieren, um die Leute wissen zu lassen, dass der Fehler vorhanden ist, aber nicht behoben wird. Stellen Sie sicher, dass der Fehlerübermittler die Gründe für Ihre Entscheidung versteht, indem Sie der Nachricht, in der das Tag wontfix hinzugefügt wird, eine Erklärung hinzufügen.

   Wenn diese Situation nicht akzeptabel ist, möchten Sie (oder der Einreicher) möglicherweise eine Entscheidung des technischen Komitees verlangen, indem Sie einen neuen Fehler gegen das Pseudopaket "tech-ctte" mit einer Zusammenfassung der Situation einreichen. Bevor Sie dies tun, lesen Sie bitte das hierzu empfohlene Verfahren.

2. Falls der Fehler zwar echt ist, jedoch ein anderes Paket betrifft, weisen Sie ihn einfach dem richtigen Paket zu. Falls Sie nicht wissen, an welches Paket er zugewiesen werden soll, sollten Sie im IRC-Kanäle oder auf debian-devel@lists.debian.org nach Hilfe fragen. Bitte informieren Sie den/die Paketbetreuer des Pakets, dem Sie den Fehler zuweisen, zum Beispiel indem Sie eine Kopie der E-Mail senden, die das erneute Zuweisen an Paketname@packages.debian.org vornimmt und erläutern Sie Ihre Beweggründe. Bitte beachten Sie, dass beim einfachen Zuweisen des Fehlers an ein anderes Paket der Betreuer dieses Pakets keine Nachricht davon erhält, so dass er nichts davon erfährt, bis er in die Fehlerübersicht seiner Pakete schaut.

   Falls der Fehler die Arbeit Ihres Pakets beeinflusst, denken Sie bitte daran, den Fehler zu klonen und den Klon dem Paket zuzuweisen, das das Verhalten tatsächlich verursacht. Andernfalls wird der Fehler nicht in Ihrer Liste der Paketfehler aufgeführt, was Anwender dazu veranlasst, den gleichen Fehler immer wieder zu melden. Sie sollten "Ihren" Fehler mit dem neu zugewiesenen, geklonten Fehler blockieren, um die Beziehung zu dokumentieren.

3. Manchmal müssen Sie außerdem den Schweregrad des Fehlers anpassen, so dass er der Debian-Definition entspricht. Dies geschieht deshalb, weil Leute die Dringlichkeit der Fehler erhöhen, um sicherzustellen, dass ihre Fehler rasch behoben werden. Einige Fehler können sogar auf den Schweregrad "wishlist" abgesenkt werden, wenn die angefragte Änderung nur kosmetischer Natur ist.

4. Falls der Fehler echt ist, das gleiche Problem aber bereits von jemand anderem gemeldet wurde, dann sollten die beiden relevanten Fehler mit dem Befehl "merge" des BTS zu einem zusammengeführt werden. Auf diese Art werden alle Absender des Fehlers informiert, wenn er behoben wurde. (Beachten Sie jedoch, dass E-Mails, die an den Absender eines Fehlerberichts gesandt werden, nicht automatisch an die Absender der anderen Berichte geschickt werden.) Weitere Details über die Form des "merge"-Befehls und des verwandten Befehls "unmerge" finden Sie in der Dokumentation des BTS-Steuerungs-Servers.

5. Der Absender des Fehlerberichts könnte vergessen haben, einige Informationen bereitzustellen. In diesem Fall müssen Sie die benötigten Informationen bei ihm erfragen. Sie könnten die Kennzeichnung moreinfo benutzen, um den Fehler entsprechend zu markieren. Außerdem können Sie den Fehler, falls sie ihn nicht reproduzieren können, als unreproducible kennzeichnen. Jeder, der den Fehler reproduzieren kann, ist dann eingeladen, weitere Informationen bereitzustellen, wie er reproduziert werden kann. Nach ein paar Monaten kann der Fehler geschlossen werden, falls diese Information von niemandem gesandt wird.

6. Falls sich der Fehler auf die Paketierung bezieht, beheben Sie ihn einfach. Falls Sie ihn nicht selbst beheben können, kennzeichnen Sie den Fehler mit help. Sie können außerdem auf debian-devel@lists.debian.org oder debian-qa@lists.debian.org um Hilfe ersuchen. Falls es ein Problem der Originalautoren ist, müssen Sie es an die Originalautoren weiterleiten. Es reicht nicht aus, den Fehler nur weiterzuleiten, Sie müssen bei jeder Veröffentlichung prüfen, ob der Fehler behoben wurde oder nicht. Falls dies der Fall ist, schließen Sie ihn, andernfalls müssen Sie den Autor später daran erinnern. Falls Sie über die erforderlichen Fähigkeiten verfügen, können Sie einen Patch vorbereiten, der den Fehler behebt und ihn dem Autor mitschicken. Stellen Sie sicher, dass Sie den Patch an das BTS senden und den Fehler mit patch kennzeichnen.

7. Falls Sie einen Fehler in Ihrer lokalen Kopie behoben haben oder eine Fehlerbehebung in das VCS-Repository übertragen wird, können Sie den Fehler als pending kennzeichnen, um die Leute wissen zu lassen, dass der Fehler behoben ist und mit dem nächsten Upload geschlossen wird (fügen Sie closes: dem changelog hinzu). Dies ist besonders nützlich, falls Sie zusammen mit mehreren Entwicklern am Paket arbeiten.

8. Sobald ein korrigiertes Paket im Archiv verfügbar ist, sollte der Fehler geschlossen und die Version, in der er behoben wurde, angegeben werden. Dies kann automatisch geschehen – lesen Sie Wann Fehler durch neue Uploads geschlossen werden.

5.8.4. Wann Fehler durch neue Uploads geschlossen werden

Sobald Fehler und Probleme in Ihren Paketen behoben werden, liegt es in Ihrer Verantwortung als Paketbetreuer, diese Fehler zu schließen. Sie sollten jedoch keinen Fehler schließen, bis das Paket, das den Fehler schließt, im Debian-Archiv akzeptiert wurde. Daher können und sollen Sie, sobald Sie die Benachrichtigung erhalten, dass Ihr aktualisiertes Paket in das Archiv installiert wurde, den Fehler im BTS schließen. Außerdem sollte der Fehler mit der korrekten Version geschlossen werden.

Es ist jedoch möglich, das manuelle Schließen von Fehlern nach dem Upload zu vermeiden – führen Sie die behobenen Fehler in Ihrer debian/changelog-Datei auf. Folgen Sie dabei einer bestimmten Syntax, dann wird die Verwaltungssoftware die Fehler für Sie schließen. Zum Beispiel:

acme-cannon (3.1415) unstable; urgency=low

  * Frobbed with options (closes: Bug#98339)
  * Added safety to prevent operator dismemberment, closes: bug#98765,
    bug#98713, #98714.
  * Added man page. Closes: #98725.

Technisch gesehen beschreibt der folgende reguläre Perl-Ausdruck, wie das Schließen von Fehlern in Änderungsprotokollen identifiziert wird:

/closes:\s*(?:bug)?\#?\s?\d+(?:,\s*(?:bug)?\#?\s?\d+)*/ig

Die Syntax closes: #XXX wird bevorzugt, da sie die kürzeste Art des Eintrags ist und am einfachsten in dem Text von changelog integriert werden kann. Falls nicht durch den Schalter -v von dpkg-buildpackage etwas anderes angegeben wurde, werden nur die Fehler im aktuellsten Eintrag des Änderungsprotokolls geschlossen (grundsätzlich werden exakt die Fehler geschlossen, die in der Datei .changes im "changelog"-Teil genannt werden).

Früher wurden Uploads, die als Non-Maintainer Uploads (NMUs) erkannt wurden, als fixed statt als "closed" gekennzeichnet, aber diese Praxis wurde mit dem Beginn der Versionsverfolgung eingestellt. Das gleiche geschah mit der Markierung fixed-in-experimental.

Sollte es passiert sein, dass Sie eine falsche Bugnummer benutzt oder einen Bugreport in der Changelog Datei vergessen haben dann zögern Sie nicht diesen Fehler rückgängig zu machen. Um falsch geschlossene Bugreports wieder zu öffnen, senden Sie das Kommando reopen XXX an die BTS-Kontrolladresse control@bugs.debian.org. Um noch ausstehende Bugreports, die durch Ihren Upload gefixt worden sind, zu schließen, senden Sie die .changes Datei an XXX-done@bugs.debian.org, wobei XXX der Bugnummer entspricht. Fügen Sie Version: YYY in die erste Zeile gefolgt von einer Leerzeile (also insgesamt zwei Zeilen) in den Body der E-Mail, YYY entspricht der ersten Paketversion in der der gemeldete Fehler gefixt worden ist.

Behalten Sie im Gedächnis, dass es nicht verpflichend ist, Fehler unter Benutzung des Änderungsprotokolls zu schließen, wie oben beschrieben. Falls Sie nur einfach einen Fehler schließen möchten, der mit dem von Ihnen getätigten Upload nichts zu tun hat, können Sie dies durch Mailen einer Erläuterung an XXX-done@bugs.debian.org erledigen. Schließen Sie keine Fehler im Änderungsprotokolleintrag einer Version, wenn die Änderungen in dieser Version des Pakets keine Bedeutung für den Fehler haben.

Allgemeine Informationen über das Verfassen von Änderungsprotokolleinträgen finden Sie unter Optimale Vorgehensweisen für debian/changelog.

5.8.5. Handhabung von sicherheitsrelevanten Fehlern

Aufgrund ihrer sensiblen Natur müssen sicherheitsrelevante Fehler vorsichtig gehandhabt werden. Das Debian-Sicherheits-Team existiert, um diese Aktivitäten zu koordinieren, ausstehende Sicherheitsprobleme zu verfolgen, Paketbetreuern bei Sicherheitsproblemen zu helfen oder sie selbst zu beheben, Sicherheitsankündigungen zu versenden und security.debian.org zu verwalten.

Wenn Sie einen sicherheitsrelevanten Fehler in einem Debian-Paket bemerken - auch wenn Sie nicht der Betreuer sind - sammeln Sie sachdienliche Informationen über das Problem und kontaktieren Sie umgehend das Sicherheits-Team per E-Mail an team@security.debian.org. Sie können die E-Mail, falls gewünscht, mit dem Debian-Security-Contact-Schlüssel chiffrieren. Einzelheiten finden Sie unter https://www.debian.org/security/faq#contact. LADEN SIE KEINE Pakete für Stable hoch, ohne das Team zu kontaktieren. Nützliche Informationen sind beispielsweise:

• Ob der Fehler bereits öffentlich ist oder nicht.

• Von welchen Versionen des Pakets bekannt ist, dass sie vom Fehler betroffen sind. Prüfen Sie jede Version, die es in einem unterstützten Debian-Release gibt, ebenso wie Testing und Unstable.

• Die Art der Fehlerbehebung, falls verfügbar (Patches sind besonders hilfreich).

• Jedes korrigierte Paket das Sie für sich selbst vorbereitet haben (senden Sie das resultierende Debdiff oder alternativ nur die Dateien .diff.gz und .dsc und lesen Sie zuerst Pakete vorbereiten, um Sicherheitsthemen anzugehen).

• Jede Unterstützung die Sie zur Hilfe beim Testen anbieten können (Exploits, Regressionstests etc.).

• Jede Information die für die Ankündigung nötig ist (siehe Sicherheitsankündigungen).

Als Betreuer des Pakets sind sie verantwortlich für dessen Verwaltung, sogar im Stable-Release. Sie sind in der besten Position, um Patches zu beurteilen und aktualisierte Pakete zu testen, sehen Sie daher bitte in die folgenden Abschnitte, wie Pakete vorbereitet werden, damit sie vom Sicherheits-Team bearbeitet werden können.

5.8.5.1. Debian Security Tracker

Das Sicherheits-Team verwaltet eine zentrale Datenbank, den Debian Security Tracker. Diese enthält alle öffentlich verfügbaren Informationen, die über Sicherheitsthemen verfügbar sind: welche Pakete und Versionen betroffen oder korrigiert sind und ob daher Stable, Testing und/oder Unstable angreifbar sind. Informationen, die immer noch vertraulich sind, werden nicht zur Datenbank hinzugefügt.

Sie können diese nach einem bestimmten Thema durchsuchen, aber auch nach einem Paketnamen. Schauen Sie nach Ihrem Paket, um zu sehen, welche Themen noch offen sind. Bitte stellen Sie, falls Sie können, weitere Informationen über diese Themen bereit oder helfen Sie, diese in Ihrem Paket zu behandeln. Anweisungen finden Sie auf den Webseiten des Security Trackers.

5.8.5.2. Vertraulichkeit

Anders als bei den meisten anderen Aktivitäten innerhalb von Debian werden Informationen über Sicherheitsthemen eine Zeit lang geheim gehalten. Dies erlaubt es Software-Vertreibern, ihre Offenlegung zu koordinieren, um die Belastung ihrer Anwender zu minimieren. Ob dies der Fall ist, hängt von der Natur des Problems und der zugehörigen Fehlerbehebung ab, und ob die Angelegenheit bereits an die Öffentlichkeit durchgesickert ist.

Es gibt mehrere Möglichkeiten, wie Entwickler von einem Sicherheitsproblem erfahren:

• sie bemerken es in einem öffentlichen Forum (Maillingliste, Website etc.)

• jemand verfasst einen Fehlerbericht

• jemand informiert sie per privater E-Mail

In den ersten beiden Fällen ist die Information öffentlich und es ist wichtig, so schnell wie möglich eine Fehlerbehebung zu haben. Im letzen Fall könnte die Information nicht öffentlich sein, In diesem Fall gibt es ein paar mögliche Optionen, mit dem Problem umzugehen:

• Falls die Offenlegung der Sicherheit gering ist, ist es manchmal nicht nötig, das Problem geheim zu halten und es sollte eine Fehlerbehebung erstellt und veröffentlicht werden.

• Falls das Problem ernst ist, sollte diese Information vorzugsweise mit anderen Anbietern geteilt werden, um eine Veröffentlichung zu koordinieren. Das Sicherheits-Team hält Kontakt zu verschiedenen Organisationen und Einzelpersonen, die sich darum kümmern.

Wenn die Person, die das Problem meldet, darum bittet, dass es nicht offengelegt wird, sollte dieser Anfrage in jedem Fall Rechnung getragen werden, mit der einleuchtenden Ausnahme, das Sicherheits-Team zu informieren, damit für ein Debian-Stable-Release eine Fehlerbehebung vorbereitet werden kann. Vergessen Sie nicht, diese Tatsache zu erwähnen, wenn vertrauliche Informationen zum Sicherheits-Team gesandt werden.

Bitte beachten Sie, dass Sie keine Fehlerbehebung nach Unstable (oder an eine andere Stelle, wie ein öffentliches VCS-Repository) senden können, wenn Geheimhaltung nötig ist. Es reicht nicht aus, die Einzelheiten der Änderung zu verschleiern, da der Code selbst öffentlich ist und von der Allgemeinheit untersucht werden kann (und soll).

Es gibt zwei Gründe, Informationen sogar dann zu veröffentlichen, wenn um Geheimhaltung gebeten wurde: Das Problem ist bereits seit einer Weile bekannt oder es wurde ein Exploit veröffentlicht.

Das Sicherheits-Team hat einen PGP-Schlüssel, um verschlüsselte Kommunikation über sensible Themen zu ermöglichen. Einzelheiten finden Sie in der Debian Sicherheits-FAQ.

5.8.5.3. Sicherheitsankündigungen

Sicherheitsankündigungen werden nur für die aktuelle, veröffentlichte Stable-Distribution ausgegeben und nicht für Testing oder Unstable. Wenn Sie veröffentlicht werden, werden sie an die Mailingliste debian-security-announce@lists.debian.org geschickt und auf der Website für Sicherheits-Informationen veröffentlicht. Sicherheitsankündigungen werden vom Sicherheits-Team verfasst und verschickt. Es ist natürlich nicht von Nachteil, wenn ein Paketbetreuer einige Informationen dazu bereitstellen kann oder einen Teil des Textes verfasst. Informationen, die in einer Ankündigung enthalten sein sollten:

• Eine Beschreibung des Problems und seines Geltungsbereichs, einschließlich:

  • Dem Typ des Problems (Rechteausweitung, Dienstverweigerung etc.)

  • Welche Privilegien können erlangt werden und durch wen (falls zutreffend)?

  • Wie kann dies ausgenutzt werden?

  • Ist es aus der Ferne oder lokal ausnutzbar?

  • Wie wurde das Problem gelöst?

  Diese Informationen ermöglichen es Anwendern, die Bedrohung ihrer Systeme zu beurteilen.

• Versionsnummern betroffener Pakete

• Versionsnummern korrigierter Pakete

• Informationen, woher man die aktualisierten Pakete bekommen kann (üblicherweise aus dem Debian-Sicherheitsarchiv)

• Referenzen zu Ankündigungen der Originalautoren, CVE-Bezeichner und jede andere nützliche Information in Querverweisen zur Schwachstelle

5.8.5.4. Pakete vorbereiten, um Sicherheitsthemen anzugehen

Eine Möglichkeit, dem Sicherheits-Team bei seinen Aufgaben zu helfen, besteht darin, es mit korrigierten Paketen zu versorgen, die für eine Sicherheitsankündigung für das Stable-Release geeignet sind.

Wenn eine Aktualisierung am Stable-Release vorgenommen wird, muss dabei behutsam vorgegangen werden, damit eine Änderung des Systemverhaltens vermieden wird und keine neuen Fehler eingeschleppt werden. Um dies zu erreichen, ändern Sie so wenig wie möglich, wenn Sie Fehler beheben. Anwender und Administratoren verlassen sich auf das exakte Verhalten des Releases, nachdem es veröffentlicht wurde, so dass jegliche vorgenommene Änderung das System von jemandem stören könnte. Dies trifft im Besonderen auf Bibliotheken zu: Stellen Sie sicher, dass Sie nie das API (Application Program Interface) oder das ABI (Application Binary Interface) ändern, egal wie klein die Änderung auch sein mag.

Dies bedeutet, dass das Umschwenken auf eine neue Originalversion keine gute Lösung ist. Stattdessen sollten die passenden Änderungen auf die Versionen im aktuellen Debian-Stable-Release zurückportiert werden. Generell sind Original-Paketbetreuer bereit zu helfen, wenn nötig. Falls nicht, könnte das Debian-Sicherheits-Team in der Lage sein zu helfen.

In manchen Fällen ist es unmöglich, eine Sicherheitskorrektur zurück zu portieren, zum Beispiel, wenn große Teile des Quellcodes geändert oder überschrieben werden müssten. Falls dies der Fall ist, könnte es nötig sein, zu einer neuen Originalversion zu wechseln. Dies wird jedoch nur in extremen Situationen getan und Sie müssen dies immer vorab mit dem Sicherheits-Team abstimmen.

Darauf bezieht sich eine weitere wichtige Regel: Testen Sie immer Ihre Änderungen. Falls Sie über ein Exploit verfügen, probieren Sie es aus und kontrollieren Sie, ob es wirklich beim nicht korrigierten Paket erfolgreich ist und am korrigierten Paket scheitert. Testen Sie auch andere normale Aktionen, da eine Sicherheitskorrektur manchmal scheinbar nicht betroffene Funktionen auf subtile Weise stört.

Nehmen Sie KEINE Änderungen in Ihr Paket auf, die sich nicht direkt auf die Behebung der Schwachstelle beziehen. Diese müssten rückgängig gemacht werden, was Zeit kostet. Falls es in Ihrem Paket andere Fehler gibt, die Sie gerne beheben würden, machen Sie auf dem üblichen Weg ein Upload nach "proposed-updates", nachdem die Sicherheitsankündigung veröffentlicht wurde. Der Sicherheits-Aktualisierungsmechanismus ist kein Mittel, um Änderungen an Ihrem Paket einzuführen, die andernfalls vom Stable-Release abgelehnt worden wären, unterlassen sie dies also.

Überprüfen und testen Sie Ihre Änderungen so ausgiebig wie möglich. Prüfen Sie die Unterschiede zur vorherigen Version mehrmals (interdiff aus dem Paket patchutils und debdiff aus devscripts sind nützliche Werkzeuge dafür, siehe debdiff).

Überprüfen Sie unbedingt folgende Elemente:

• Geben Sie die richtige Distribution als Ziel in Ihrem debian/changelog an: codename-security (z.B. bookworm-security). Geben Sie nicht Distribution-proposed-updates oder Stable als Ziel an!

• Verfassen Sie anschauliche, aussagekräftige Änderungsprotokolleinträge. Andere werden sich darauf verlassen, um zu bestimmen, ob ein bestimmter Fehler behoben wurde. Fügen Sie für alle eingereichten Debian-Fehler closes:-Angaben hinzu. Beziehen Sie immer einen externen Bezug ein, vorzugsweise einen CVE-Bezeichner, so dass Querverweise darauf möglich sind. Wenn ein CVE-Bezeichner jedoch noch nicht zugewiesen wurde, warten Sie nicht darauf, sondern fahren Sie mit dem Prozess fort. Ein späterer Querverweis auf den Bezeichner ist möglich.

• Stellen Sie sicher, dass die Versionsnummer angemessen ist. Sie muss größer als die des aktuellen Pakets, aber kleiner als die von Paketversionen in neueren Distributionen sein. Falls es Zweifel gibt, prüfen Sie es mit dpkg --compare-versions. Seien Sie vorsichtig, dass Sie keine Versionsnummer wiederverwenden, die Sie für ein vorheriges Hochladen benutzt haben, oder eine, die Konflikte mit einem binNMU auslöst. Es ist Brauch, +debXu1 anzuhängen (wobei X die Major-Release-Nummer ist), z.B. 1:2.4.3-4+deb12u1 und natürlich muss dies bei jedem nachfolgendem Hochladen um eins zu erhöht werden.

• Sofern der Originalquellcode nicht vorher nach security.debian.org hochgeladen wurde (durch eine vorhergehende Sicherheitsaktualisierung), erstellen Sie den Upload aus vollständigen Originalquellen (dpkg-buildpackage -sa). Falls es einen vorhergehenden Upload nach security.debian.org mit der gleichen Originalversion gab, könnten Sie ohne den Originalquellcode hochladen (dpkg-buildpackage -sd).

• Tragen Sie Sorge, dass die exakt gleiche *.orig.tar.{gz,bz2,xz}-Datei wie im normalen Archiv benutzt wird. Andernfalls ist es nicht möglich, die Sicherheitskorrektur später in die Hauptarchive zu verschieben.

• Erstellen Sie das Paket auf einem sauberen System, auf dem nur Pakete der Distribution installiert sind, für die Sie das Paket erstellen. Falls Sie selbst nicht über ein solches System verfügen, können Sie eine debian.org-Maschine verwenden (siehe Debian-Maschinen) oder richten Sie ein Chroot ein (siehe pbuilder und debootstrap).

5.8.5.5. Hochladen eines korrigierten Pakets

Laden Sie KEIN Paket in die Sicherheits-Upload-Warteschlange (auf security-master.debian.org) ohne vorherige Genehmigung des Sicherheits-Teams. Falls das Paket nicht exakt den Anforderungen des Teams entspricht, wird es viele Probleme und Verzögerungen im Umgang mit dem unerwünschten Upload verursachen.

Laden Sie ihre Fehlerbehebung NICHT nach proposed-updates ohne Abstimmung mit dem Sicherheits-Team hoch. Pakete von security.debian.org werden automatisch direkt in das Verzeichnis proposed-updates kopiert. Falls bereits ein Paket mit der gleichen oder einer höheren Versionsnummer im Archiv installiert ist, wird die Sicherheitsaktualisierung durch das Archivsystem abgelehnt. Stattdessen endet auf diese Weise die Distribution Stable ohne eine Sicherheitsaktualisierung für dieses Paket.

Sobald Sie das neue Paket erstellt und getestet haben und es vom Sicherheits-Team zugelassen wurde, muss es hochgeladen werden, so dass es in den Archiven installiert werden kann. Sicherheits-Uploads werden dabei nach ftp://security-master.debian.org/pub/SecurityUploadQueue/ hochgeladen.

Sobald ein Upload in die Sicherheitheitswarteschlange akzeptiert wurde, wird das Paket automatisch für alle Architekturen erstellt und zur Überprüfung durch das Sicherheits-Team gespeichert.

Auf Uploads, die auf Zustimmung oder Prüfung warten, kann nur das Sicherheits-Team zugreifen. Dies ist nötig, da es sich um Fehlerbehebungen für Sicherheitsprobleme handeln könnte, die noch nicht offengelegt werden dürfen.

Falls ein Mitglied des Sicherheits-Teams ein Paket akzeptiert, wird es auf security.debian.org installiert. Ebenso wird es für das passende Distribution-proposed-updates auf ftp-master.debian.org vorgeschlagen.

5.9. Verschieben, Entfernen, Verwaisen, Adoptieren und Wiedereinführen von Paketen

Einige Operationen zum Manipulieren von Archiven sind im Debian-Upload-Prozess nicht automatisiert. Diese Prozeduren sollten manuell durch Paketbetreuer abgewickelt werden. Dieses Kapitel gibt einen Leitfaden, was in diesen Fällen zu tun ist.

5.9.1. Pakete verschieben

Manchmal ändert ein Paket seinen Bereich. Ein Paket aus dem Bereich non-free könnte zum Beispiel in einer neueren Version unter der GPL erscheinen. In diesem Fall sollte es nach "main" oder "contrib" verschoben werden. [1]

Falls Sie für eines Ihrer Pakete den Bereich ändern müssen, ändern Sie die control-Information des Pakets, um es in den gewünschten Bereich zu platzieren und laden Sie das Paket erneut hoch (Einzelheiten finden Sie im Debian Policy Manual). Sie müssen sicherstellen, dass Sie Ihrem Upload die .orig.tar.{gz,bz2,xz}-Datei beifügen (sogar, wenn Sie keine neue Originalversion hochladen), sonst wird es nicht zusammen mit dem Rest des Pakets in dem neuen Bereich erscheinen. Falls Ihr neuer Bereich gültig ist, wird es automatisch verschoben. Falls dies nicht geschieht, wenden Sie sich an die Ftpmasters, damit Sie verstehen, was geschehen ist.

Falls Sie andererseits die subsection eines Ihrer Pakete ändern müssen (z.B. "devel", "admin"), ist die Prozedur etwas anders. Korrigieren Sie den in der control-Datei enthaltenen Unterbereich des Pakets und laden Sie es erneut hoch. Außerdem müssen Sie die Datei "override" aktualisieren, wie es in Angabe des Paketbereichs, des Unterbereichs und der Priorität beschrieben wird.

5.9.2. Pakete entfernen

Falls Sie aus irgendeinem Grund ein Paket vollständig entfernen möchten (etwa, weil es eine alte Kompatibilitätsbibliothek ist, die nicht länger erforderlich ist), müssen Sie einen Fehler gegen ftp.debian.org einreichen, in dem Sie darum bitten, das Paket zu entfernen. Wie alle Fehler sollte auch dieser standardmäßig den Schweregrad "normal" haben. Der Fehlertitel sollte die Form RM: Paket[Architekturenliste] -- Grund haben, wobei Paket der Name des zu entfernenden Pakets und Grund eine kurze Zusammenfassung sein sollte, aus welchem Grund um Entfernen gebeten wird. [Architekturenliste] ist optional und wird nur benötigt, wenn das Entfernen lediglich einige Architekturen betrifft, aber nicht alle. Beachten Sie, dass reportbug einen Titel erstellt, der diesen Regeln entspricht, wenn Sie es benutzen, um einen Fehler des Pseudo-Pakets ftp.debian.org zu melden.

Falls Sie ein von Ihnen betreutes Paket entfernen wollen, sollten Sie dies im Titel des Fehlerberichts durch Voranstellen von ROM (Request Of Maintainer) anmerken. Es gibt mehrere andere Standardabkürzungen, die als Grund für das Entfernen von Paketen benutzt werden. Eine komplette Liste finden Sie unter https://ftp-master.debian.org/removals.html. Diese Seite stellt außerdem einen praktischen Überblick über ausstehende Anfragen zum Entfernen bereit.

Beachten Sie, dass Pakete nur aus den Distributionen Unstable, Experimental und Stable entfernt werden können. Pakete werden nicht direkt aus Testing entfernt. Sie werden vielmehr automatisch entfernt, nachdem das Paket aus Unstable entfernt wurde und in Testing kein Paket davon abhängt. (Etwas aus Testing zu entfernen, ist durch Einreichen eines Fehlerberichts an das Pseudopaket release.debian.org möglich, siehe Entfernen aus Testing.)

Es gibt eine Ausnahme, bei der eine explizite Anfrage zum Entfernen nicht nötig ist: Falls ein (Quell- oder Binär-) Paket nicht länger aus dem Quellcode erstellt wird, wird es halbautomatisch entfernt. Bei einem Binärpaket ist dies der Fall, wenn kein Quellpaket dieses Binärpaket weiterhin erzeugt. Falls das Binärpaket nur auf einigen Architekturen nicht länger erstellt wird, ist eine Anfrage zum Entfernen weiterhin nötig. Für ein Quell-Paket bedeutet dies, dass alle Binärpakete, die sich darauf beziehen, von einem anderen Quellpaket übernommen werden müssen.

In Ihrer Bitte um Entfernung müssen Sie detaillierte Gründe angeben, die das Entfernen rechtfertigen. Dies muss so sein, um unerwünschtes Entfernen zu vermeiden und um eine Chronik aufzubewahren, weshalb das Paket entfernt wurde. Sie können zum Beispiel den Namen des Pakets bereitstellen, dass das Entfernte ersetzt.

Üblicherweise bitten Sie nur darum, ein Paket zu entfernen, das Sie selbst betreuen. Falls Sie ein anderes Paket entfernen möchten, müssen Sie die Genehmigung seines Betreuers einholen. Sollte das Paket verwaist sein und daher keinen Betreuer haben, sollten Sie die Bitte um Entfernung zuerst auf debian-qa@lists.debian.org diskutieren. Falls es dort eine Übereinkunft gibt, dass das Paket entfernt werden soll, sollten Sie den bestehenden O:-Fehlerreport gegen das wnpp-Paket umbenennen und entsprechend zuweisen, anstatt einen neuen Fehlerbericht mit Bitte um Entfernen einzureichen.

Weitere Informationen über diese oder andere Themen, die sich auf das Entfernen von Paketen beziehen, finden Sie unter https://wiki.debian.org/ftpmaster_Removals und https://qa.debian.org/howto-remove.html.

Wenn Zweifel bestehen ob ein Paket verworfen werden kann, fragen Sie per E-Mail an debian-devel@lists.debian.org nach Meinungen. Außerdem ist das Programm apt-cache aus dem Paket apt von Interesse. Wenn es mit apt-cache showpkg Paket aufgerufen wird, zeigt es Einzelheiten über das Paket, einschließlich umgekehrter Abhängigkeiten. Andere nützliche Programme umfassen apt-cache rdepends, apt-rdepends, build-rdeps (aus dem Paket devscripts) und grep-dctrl. Das Entfernen von verwaisten Paketen wird auf debian-qa@lists.debian.org diskutiert.

Sobald das Paket entfernt wurde, sollten die Fehler des Pakets behandelt werden. Sie sollten entweder im Fall, dass der tatsächliche Code in ein anderes Paket übergegangen ist, entsprechend zugewiesen werden (z.B. libfoo12 wurde entfernt, weil libfoo13 es ersetzt) oder geschlossen werden, falls die Software einfach nicht länger Teil von Debian ist. Wenn die Fehler geschlossen werden, sollten sie in der Version <most-recent-version-ever-in-Debian>+rm als behoben gekennzeichnet werden, um zu verhindern, dass sie in vorherigen Debian-Releases als behoben gekennzeichnet werden.

5.9.2.1. Entfernen von Paketen aus Incoming

Früher war es möglich, Pakete aus incoming zu entfernen. Mit der Einführung des neuen Incoming-Systems ist dies jedoch nicht mehr möglich. [4] Stattdessen müssen Sie eine neue Überarbeitung Ihres Pakets mit einer höheren Versionsnummer als der des zu ersetzenden Pakets hochladen. Beide Versionen werden im Archiv installiert, aber nur die höhere Version wird tatsächlich in Unstable verfügbar sein, da die vorherige sofort durch die höhere ersetzt wird. Falls Sie jedoch Ihr Paket ordnungsgemäß testen, sollte es ohnehin nicht allzu oft vorkommen, dass Sie ein Paket ersetzen.

5.9.3. Umbenennen oder Ersetzen von Paketen

Wenn sich die Originalautoren eines Ihrer Pakete entscheiden, ihre Software umzubenennen (oder Ihnen beim Benennen Ihres Pakets ein Fehler unterlaufen ist), sollten Sie einen zweistufigen Prozess durchlaufen, um es umzubenennen. Im ersten Schritt ändern Sie die Datei debian/control, um den neuen Namen wiederzugeben, der den veralteten ersetzt, dessen Funktionalität wieder bereitstellt und zu ihm in Konflikt tritt (Einzelheiten finden Sie im Debian Policy Manual). Bitte beachten Sie, dass Sie nur dann eine Provides-Beziehung hinzufügen sollten, wenn alle Pakete, die von dem veralteten Paketnamen abhängen, nach dem Umbenennen weiter funktionieren. Sobald Sie das Paket hochgeladen haben und das Paket in das Archiv verschoben wurde, reichen Sie einen Fehler gegen ftp.debian.org ein, in dem Sie um das Entfernen des veralteten Namens ersuchen (siehe Pakete entfernen). Vergessen Sie nicht, gleichzeitig die Fehler passend zuzuweisen.

Eine andere Situation wäre, dass Sie einen Fehler beim Konstruieren Ihres Pakets begangen haben und wünschen, es zu ersetzen. Die einzige Möglichkeit, dies zu tun, besteht im Erhöhen der Versionsnummer und dem Hochladen dieser neuen Version. Die alte Version verliert wie üblich ihre Gültigkeit. Beachten Sie, dass dies auf jeden Teil Ihres Pakets zutrifft, einschließlich dem Quellcode: Falls Sie den Originalquell-Tarball Ihres Pakets ersetzen möchten, müssen Sie ihn mit einer veränderten Version hochladen. Eine einfache Möglichkeit ist es, foo_1.00.orig.tar.gz durch foo_1.00+0.orig.tar.gz oder foo_1.00.orig.tar.bz2 zu ersetzen. Diese Einschränkung gibt jeder Datei auf der FTP-Seite einen einzigartigen Namen, der dabei hilft, die Einheitlichkeit über ein Netzwerk von Spiegelservern sicherzustellen.

5.9.4. Verwaisen von Paketen

Falls Sie ein Paket nicht länger betreuen können, müssen Sie andere darüber informieren und dafür sorgen, dass das Paket als verwaist gekennzeichnet wird. Sie sollten den Paketbetreuer auf Debian QA Group <packages@qa.debian.org> setzen und einen Fehlerbericht gegen das Pseudopaket wnpp senden. Der Fehlerbericht sollte im Betreff O: Paket -- kurze Beschreibung enthalten um so anzuzeigen, dass das Paket nun verwaist ist. Der Schweregrad des Fehlers sollte auf normal gesetzt werden falls das Paket die Priorität "standard" oder höher hat, sollte der Schweregrad auf "important" gesetzt werden. Wenn Sie es für nötig halten, senden Sie eine Kopie an debian-devel@lists.debian.org, indem Sie die Adresse in die Kopfzeile X-Debbugs-CC: der Nachricht einfügen (nein, benutzen Sie nicht CC:, da auf diese Art der Betreff der Nachricht die Fehlernummer nicht angibt).

Falls Sie nur die Absicht haben, das Paket abzugeben, aber im Moment noch Betreuer bleiben können, dann sollten Sie stattdessen einen Fehlerbericht gegen wnpp mit dem Betreff RFA:Paket-- kurze Beschreibung senden. RFA steht für Request For Adoption (Bitte um Adoption).

Weitere Informationen finden Sie auf den WNPP-Web-Seiten.

5.9.5. Adoption eines Pakets

Eine Liste von Paketen, die einen neuen Betreuer suchen, ist unter Arbeit-bedürfende und voraussichtliche Pakete (WNPP) verfügbar. Falls Sie die Verwaltung von einigen Paketen übernehmen möchten, die auf WNPP aufgeführt sind, lesen Sie bitte besagte Seite, um Informationen zu erhalten und etwas über die Prozeduren zu erfahren.

Es ist nicht in Ordnung, einfach ein Paket ohne Zustimmung des derzeitigen Betreuers zu übernehmen – das wäre Paketentführung. Sie können natürlich den aktuellen Betreuer kontaktieren und ihn fragen, ob Sie das Paket übernehmen dürfen.

Wenn ein Paket vom Betreuer jedoch vernachlässigt wurde, können Sie möglicherweise die Paketbetreuung übernehmen, indem Sie dem in Pakete bergen beschriebenen Paket-Bergungsprozess folgen. Wenn Sie Grund zur Annahme haben, dass ein Betreuer überhaupt nicht mehr aktiv ist, lesen Sie Sich mit inaktiven und/oder nicht erreichbaren Paketbetreuern beschäftigen.

Beschwerden über Betreuer sollten auf der Entwickler-Mailingliste vorgebracht werden. Falls die Diskussion mit keinem positiven Fazit endet und das Thema technischer Natur ist, erwägen Sie, den Technischen Ausschuss darauf aufmerksam zu machen. Weitere Informationen finden Sie unter Debians Technischer Ausschuss.

Wenn Sie ein altes Paket übernehmen, möchten Sie wahrscheinlich als offizieller Betreuer in der Fehlerdatenbank aufgeführt werden. Dies geschieht automatisch, sobald Sie eine neue Version mit einem aktualisierten Maintainer-Feld hochladen, obwohl dies nach dem Hochladen ein paar Tage dauern kann. Falls Sie für eine Weile nicht planen, eine neue Version hochzuladen, können Sie Das Debian-Paketverfolgungssystem benutzen, um Fehlerberichte zu erhalten. Stellen Sie jedoch sicher, dass der alte Betreuer kein Problem damit hat, dass er während dieser Zeit weiterhin die Fehlerberichte erhalten wird.

5.9.6. Wiedereinführen vom Paketen

Pakete werden oft aufgrund veröffentlichungskritischer Fehler, fehlender Paketbetreuer, zu weniger Benutzer oder allgemein schlechter Qualität entfernt. Obwohl der Prozess der Wiedereinführung dem anfänglichen Paketierungsprozess ähnlich ist, können Sie einige Tücken umgehen, indem Sie zuerst etwas historische Recherche betreiben.

An erster Stelle sollten Sie prüfen, weshalb das Paket entfernt wurde. Diese Information können Sie unter dem Punkt Remove im News-Bereich auf der PTS-Seite des Pakets finden oder durch Durchstöbern des Protokolls unter Removed packages. Der Fehlerbericht für das Entfernen wird Ihnen sagen, weshalb das Paket entfernt wurde und einen Hinweis darauf geben, woran Sie arbeiten müssen, um das Paket wieder einzuführen. Möglicherweise gibt er auch an, dass Sie am Besten mit einer anderen Software weitermachen, anstatt das Paket wieder einzuführen.

Es ist vielleicht angebracht, die früheren Paketbetreuer zu kontaktieren, um herauszufinden, ob sie an der Wiedereinführung des Pakets arbeiten, ob sie es mitbetreuen möchten oder ob sie interessiert sind, das Paket, falls nötig, zu sponsern.

Sie sollten all die Dinge tun, die erforderlich sind, um neue Pakete einführen (Neue Pakete).

Sie sollten auf Basis der letzten verfügbaren Paketierung arbeiten, die sich eignet. Dies kann die letzte Version aus Unstable sein, die immer noch im Snapshot-Archiv vorhanden ist.

Das vom letzten Paketbetreuer benutzte Versionskontrollsystem kann nützliche Änderungen enthalten, daher ist es vermutlich eine gute Idee, dort nachzusehen. Prüfen Sie, ob die Datei control des vorherigen Paket irgendwelche Kopfzeilen enthält, die auf das Versionskontrollsystem des Pakets verweisen und ob es noch existiert.

Entfernen von Paketen aus Unstable (nicht Testing, Stable oder Oldstable) löst das Schließen aller Fehler aus, die sich auf das Paket beziehen. Sie sollten alle geschlossenen Fehler durchsehen (einschließlich archivierter Fehler) und diejenigen aus dem Archiv nehmen und wieder öffnen, die mit einer Version geschlossen wurden, die auf +rm endet und die immer noch zutreffen.

Das Entfernen von Paketen aus "Unstable" löst auch das Markieren des Pakets als entfernt im Debian Security Tracker aus. Debian-Mitglieder sollten entfernte Pakete als nicht Fehler behoben im Security Tracker-Repository markieren. Alle anderen sollten sich an das Sicherheitsteam wenden, um wieder eingeführte Pakete zu melden.

5.10. Portieren und portiert werden

Debian unterstützt eine immer größer werdende Anzahl von Architekturen. Sogar wenn Sie kein Portierer sind und nur eine einzige Architektur nutzen, gehört es zu Ihren Pflichten als Betreuer, die Fragen der Portierbarkeit zu kennen. Daher sollten Sie, sogar wenn Sie kein Portierer sind, das meiste in diesem Kapitel lesen.

Portieren ist das Erstellen von Debian-Paketen für Architekturen, die sich von der Originalarchitektur des Binärpakets des Paketbetreuers unterscheiden. Es ist eine einzigartige und notwendige Aktivität. Tatsächlich sind Portierer diejenigen, die die meisten Debian-Pakete kompilieren. Wenn zum Beispiel ein Paketbetreuer ein (portierbares) Quellpaket mit Binärdateien für die Architektur i386 hochlädt, wird es für jede andere Architektur erstellt, was auf 10 weitere Builds hinausläuft.

5.10.1. Seien Sie freundlich zu Portierern

Portierer haben schwere und ungewöhnliche Aufgaben, da sie mit einer großen Zahl von Paketen umgehen müssen. Idealerweise sollte jedes Quellpaket direkt aus dem Stand korrekt erstellt werden. Unglücklicherweise ist das oft nicht der Fall. Dieser Abschnitt enthält eine Prüfliste von "Patzern", die öfter von Debian-Betreuern begangen werden – übliche Probleme, die Portierer oft in Schwierigkeiten bringen und ihre Arbeit unnötig erschweren.

Die Erste und Wichtigste ist, schnell auf einen Fehler oder ein Problem zu antworten, das ein Portierer aufgedeckt hat. Behandeln Sie Portierer höflich, als wären Sie quasi Mitbetreuer Ihres Pakets (was sie gewissermaßen sind). Bitte seien Sie tolerant bei knappen oder sogar unklaren Fehlerberichten. Tun Sie Ihr Bestes, um Jagd auf das Problem zu machen, was immer es auch ist.

Die mit Abstand meisten Probleme, die von Portierern gefunden werden, werden durch Paketierungsfehler in den Quellpaketen verursacht. Hier ist eine Liste der Dinge, die Sie prüfen oder wissen sollten.

1. Stellen Sie sicher, dass Ihre Build-Depends- und Build-Depends-Indep-Einstellungen in der Datei debian/control richtig gesetzt sind. Die beste Methode, dies zu überprüfen, ist die Benutzung des Pakets debootstrap, um eine Unstable-Chroot-Umgebung zu erstellen (siehe debootstrap). Innerhalb der Chroot-Umgebung installieren Sie das Paket build-essential und/oder Build-Depends-Indep. Am Ende versuchen Sie, Ihr Paket innerhalb der Chroot-Umgebung zu erstellen. Diese Schritte können mit dem Programm pbuilder automatisiert werden, das vom Paket mit dem gleichen Namen bereitgestellt wird (siehe pbuilder).

   Falls Sie kein ordnungsgemäßes Chroot einrichten können, könnte Ihnen dpkg-depcheck behilflich sein (siehe dpkg-depcheck).

   Anweisungen zur Einrichtung von Build-Abhängigkeiten finden Sie im Debian Policy Manual.

2. Setzen Sie "architecture" auf keinen anderen Wert als all oder any, außer wenn Sie das wirklich beabsichtigen. In zu vielen Fällen folgen Paketbetreuer nicht den Anweisungen im Debian Policy Manual. Wenn Sie Ihre "architecture" nur auf eine Architektur (wie i386 oder amd64) setzen, ist dies normalerweise falsch.

3. Stellen Sie sicher, dass das Quellpaket korrekt ist. Führen Sie dpkg-source -x Paket.dsc aus, um sicherzustellen, dass Ihr Quellpaket ordnungsgemäß entpackt wird. Dann versuchen Sie, dort Ihr Paket von Grund auf mit dpkg-buildpackage neu zu erstellen.

4. Stellen Sie sicher, dass Sie Ihr Quellpaket nicht mit den Dateien debian/files oder debian/substvars ausliefern. Sie sollten durch das Target clean von debian/rules entfernt werden.

5. Stellen Sie sicher, dass Sie sich nicht auf lokal installierte Pakete oder gehackte Konfigurationen oder Programme verlassen. Sie sollten zum Beispiel niemals Programme in /usr/local/bin oder dergleichen aufrufen. Versuchen Sie, Ihr Paket auf einem anderen Rechner zu erstellen, auch wenn dieser die gleiche Architektur hat.

6. Verlassen Sie sich nicht darauf, dass das Paket, das Sie erstellen, bereits installiert ist (ein Teilaspekt des vorherigen Problems). Es gibt natürlich Ausnahmen von dieser Regel, aber seien Sie sich bewusst, dass dies auf jeden Fall manuelles Bootstrapping erfordert und nicht durch automatisierte Paket-Builder erledigt werden kann.

7. Verlassen Sie sich, wenn möglich, nicht auf eine bestimmte Version des Compilers. Falls doch, dann stellen Sie sicher, dass Ihre Build-Abhängigkeiten diese Einschränkungen widerspiegeln, obwohl Sie sich wahrscheinlich Ärger einhandeln, da verschiedene Architekturen manchmal unterschiedliche Compiler vorgeben.

8. Sorgen Sie dafür, dass Ihre debian/rules-Datei separate binary-arch- und binary-indep-Targets enthält, wie es das Debian Policy Manual fordert. Stellen Sie sicher, dass beide Targets unabhängig voneinander funktionieren, damit Sie ein Target aufrufen können, ohne dass Sie vorher das andere aufgerufen haben müssen. Um dies zu prüfen, führen Sie dpkg-buildpackage -B aus.

9. Wenn Ihr Paket auf bestimmten Architekturen nicht unterstützt wird, sollten Sie nicht das Feld Architecture verwenden, um das widerzuspiegeln (es ist schwierig, das Feld richtig zu pflegen). Wenn das Paket nicht aus den Quellen gebaut werden kann, können Sie es einfach so lassen und interessierte Leute können sich die Build-Protokolle anschauen. Wenn das Paket bauen würde, sollte der Trick angewendet werden Build-Depends auf unsupported-architecture [!the-not-supported-arch] zu setzen. Die Buildds werden das Paket nicht bauen, da die Build-Abhängigkeiten nicht für diese Architektur erfüllt sind. Um zu verhindern, dass für 32-Bit-Architekturen gebaut wird, kann die Build-Abhängigkeit architecture-is-64-bit verwendet werden. Ebenso kann architecture-is-litte-endian verwendet werden, um zu verhindern, dass auf Big-Endian-Systemen gebaut wird.

5.10.2. Leitlinien für Uploads von Portierern

Wenn das Paket aus dem Stand für die Architektur erstellt werden kann, auf die es portiert werden soll, haben Sie Glück und Ihre Arbeit ist einfach. Dieser Abschnitt befasst sich mit diesem Fall; er beschreibt, wie Ihr Binärpaket erstellt und hochgeladen wird, so dass es ordnungsgemäß im Archiv installiert werden kann. Falls Sie das Paket patchen müssen, um es für eine andere Architektur kompilieren zu können, führen Sie in Wirklichkeit ein Quell-NMU durch, ziehen Sie daher stattdessen Wann und wie ein NMU durchgeführt wird zu Rate.

Für einen Upload eines Portierers werden keine Änderungen am Quellcode vorgenommen. Sie müssen keine Dateien im Quellpaket anfassen. Dies schließt debian/changelog ein.

Die Vorgehensweise, dpkg-buildpackage aufzurufen, ist wie folgt: dpkg-buildpackage -B -m E-Mail des Portierers. Natürlich setzen Sie E-Mail des Portierers auf Ihre E-Mail-Adresse. Dies wird zu einem rein binären Build von nur den Paketteilen führen, die architekturabhängig sind. Dabei wird in debian/rules das Target binary-arch benutzt.

Falls Sie für Ihr Portierungs-Bestreben auf einer Debian-Maschine arbeiten und Ihren Upload lokal signieren müssen, damit er im Archiv akzeptiert wird, können Sie debsign für Ihre .changes-Datei ausführen, um sie bequem zu signieren, oder benutzen Sie den Signierungsmodus aus der Ferne von dpkg-sig.

5.10.2.1. Neu kompilieren oder rein binärer NMU

Manchmal ist der erste Upload einer Portierung problematisch, da die Umgebung, in der das Paket erstellt wurde, nicht gut genug war (veraltete oder hinfällige Bibliotheken, falsche Compiler etc.). Dann könnte es nötig sein, dass Sie es nur neu in einer aktualisierten Umgebung kompilieren müssen. In diesem Fall müssen Sie jedoch die Versionsnummer ändern, so dass das alte, falsche Paket im Debian-Archiv ersetzt werden kann (dak lehnt die Installation neuer Pakete ab, falls Sie keine höheren Versionsnummern als das aktuell verfügbare haben).

Sie müssen sicherstellen, dass Ihr rein binärer NMU das Paket nicht uninstallierbar macht. Dies könnte geschehen, wenn ein Quellpaket architekturabhängige und architekturunabhängige Pakete generiert, die unter Benutzung der ersetzbaren Dpkg-Variable $(Source-Version) wechselseitige Abhängigkeiten erzeugen.

Ungeachtet der nötigen Modifikation des Änderungsprotokolls werden diese Uploads als rein binäre NMUs bezeichnet – es ist nicht nötig, in diesem Fall dafür zu sorgen, dass alle anderen Architekturen sich selbst als veraltet oder eines erneuten Kompilierens bedürfig betrachten.

Solche Neu-Kompilierungen benötigen eine spezielle "magische" Versionsnummerierung, so dass die Archiv-Verwaltungswerkzeuge dies erkennen; selbst wenn es eine neue Debian-Version ist, gibt es dort keine zugehörige Aktualisierung des Quellcodes. Falls Sie dabei einen Fehler machen, werden die Archivbetreuer Ihre Aktualisierung ablehnen (aus Mangel an entsprechendem Quellcode).

Die "Magie" für ein reines Neu-Kompilierungs-NMU wird durch eine Endung ausgelöst, die an die Paketversionsnummer angehängt wird und die Form bZahl hat. Wenn etwa die letzte Version, die Sie kompilierten, 2.9-3 war, sollte Ihr rein binärer NMU die Versionsnummer 2.9-3+b1 tragen. Falls die letzte Version 3.4+b1 war (d.h. ein natives Paket mit einem vorhergehenden Neu-Kompilierungs-NMU), sollte Ihr rein binärer NMU die Versionsnummer 3.4+b2. [2] haben.

Ähnlich wie bei ersten Portierungs-Uploads ist der korrekte Weg, dpkg-buildpackage aufzurufen, dpkg-buildpackage -B, um nur die architekturabhängigen Teile des Pakets zu erstellen.

5.10.2.2. Wann Sie als Portierer ein Quell-NMU durchführen sollten

Portierer, die einen Quell-NMU durchführen, folgen generell den Leitlinien, die unter Non-Maintainer Uploads (NMUs) aufgeführt sind, genau wie nicht-Portierer. Es wird jedoch erwartet, dass der Wartezyklus für den Quell-NMU eines Portierers kleiner ist, als der von nicht-Portierern, da Portierer mit einer großen Zahl von Paketen zurechtkommen müssen. Die Situation variiert wiederum abhängig von der Distribution, in die hochgeladen wird. Sie variiert außerdem in Abhängigkeit davon, ob die Architektur ein Kandidat für die Integration in das nächste Stable-Release ist. Die Veröffentlichungsverwalter entscheiden, welche Architekturen Kandidaten sind und kündigen dies an.

Falls Sie als Portierer einen NMU für Unstable durchführen, sollten die vorher genannten Regeln der Portierung mit zwei Abwandlungen befolgt werden. Erstens ist die akzeptable Wartezeit – die Zeit zwischen dem Absenden des Fehlerberichts an das BTS und der Zeit, wenn es in Ordnung ist, einen NMU durchzuführen – sieben Tage für Portierer, die an der Distribution Unstable arbeiten. Diese Zeitspanne kann verkürzt werden, falls das Problem kritisch ist und eine Notlage für die Portierungsanstrengung nach Ermessen der Gruppe der Portierer besteht. (Bedenken Sie, dass nichts davon in den Debian-Richtlinien steht, die Entwickler haben sich lediglich auf gewisse Regeln diesbezüglich geeinigt.) Für Uploads nach Stable oder Testing stimmen Sie sich bitte zuerst mit dem Release-Team ab.

Zweitens sollten Portierer, die ein Quell-NMU durchführen, sicherstellen, dass der Fehler, den Sie an das BTS senden, den Schweregrad serious oder höher aufweist. Dies garantiert, dass ein einzelnes Quellpaket benutzt werden kann, um jede unterstützte Debian-Architektur zum Veröffentlichungszeitpunkt zu kompilieren. Es ist sehr wichtig, dass es eine Version des Quell- und Binärpakets für alle Architekturen gibt, um vielen Lizenzen zu entsprechen.

Portierer sollten versuchen, Patches zu vermeiden, die einfache Bastellösungen für Fehler in der aktuellen Version der Compiler-Umgebung, des Kernels oder der Libc enthalten. Bisweilen sind solche Bastellösungen nicht hilfreich. Falls Sie an Compiler-Fehlern und dergleichen herumbasteln müssen, stellen Sie sicher, dass Sie Ihre Arbeit ordnungsgemäß in #ifdef einschließen. Dokumentieren Sie außerdem Ihren Murks, damit die Leute wissen, dass er entfernt werden muss, sobald die externen Probleme behoben wurden.

Portierer könnten außerdem einen inoffiziellen Ort haben, an dem sie die Ergebnisse Ihrer Arbeit während der Wartezeit ablegen. Dies hilft anderen, die an der Portierung arbeiten, sogar während der Wartezeit aus der Arbeit des Portierers Nutzen zu ziehen. Natürlich haben solche Orte keinen offiziellen Segen oder Status, daher nehme sich der Käufer in Acht.

5.10.3. Portierungs-Infrastruktur und -Automatisierung

Es gibt eine Infrastruktur und mehrere Werkzeuge, die das Portieren von Paketen automatisieren. Dieser Abschnitt enthält einen kurzen Überblick dieser Automatisierung und Portierung mit diesen Werkzeugen. Lesen Sie die Paketdokumentation oder die Referenzen, um umfassende Informationen zu erhalten.

5.10.3.1. Mailinglisten und Web-Seiten

Web-Seiten, die den Status jeder Portierung enthalten, finden Sie unter https://www.debian.org/ports/.

Jede Portierung von Debian hat eine Mailingliste. Die Liste der Portierungs-Mailinglisten sind unter https://lists.debian.org/ports.html zu finden. Diese Listen werden benutzt, um die Arbeit der Portierer zu koordinieren und um eine Verbindungsschnittstelle der Anwender der Portierung zu den Portierern herzustellen.

5.10.3.2. Werkzeuge der Portierer

Beschreibungen von vielen Werkzeugen für die Portierung finden Sie unter Portierungswerkzeuge.

5.10.3.3. wanna-build

Das System wanna-build wird als verteiltes Client-/Server-Build-Verteilungssystem eingesetzt. Es wird üblicherweise zusammen mit Build-Daemons benutzt, die das Programm buildd ausführen. Build daemons sind "Slave"-Rechner, die das zentrale wanna-build-System kontaktieren, um eine Liste der Pakete zu beziehen, die erstellt werden müssen.

wanna-build ist noch nicht als Paket verfügbar. Alle Debian-Portierungsbestrebungen benutzen es jedoch zur automatisierten Paketerstellung. Das Werkzeug sbuild, das für die tatsächlichen Paket-Builds benutzt wird, ist allerdings als Paket verfügbar. Lesen Sie dessen Beschreibung unter sbuild. Bitte beachten Sie, dass sich die Paketversion auf den Build-Daemons unterscheidet, aber sie sind ähnlich genug, um Probleme nachvollziehen zu können.

wanna-build ist generell für Portierer nützlich. Die meisten davon erzeugten Daten sind im Web unter https://buildd.debian.org/verfügbar. Diese Daten enthalten nächtlich aktualisierte Statistiken, Warteschlangeninformationen und Protokolle von Build-Versuchen.

Debian ist ziemlich stolz auf dieses System, da es so viele Verwendungsmöglichkeiten gibt. Unabhängige Entwicklergruppen können das System benutzen, um unterschiedliche Geschmacksrichtungen von Debian, die von allgemeinem Interesse sein können oder auch nicht (zum Beispiel eine Debian-Geschmacksrichtung, die mit "bounds checking" vom gcc erstellt wurde) zu erstellen. Dadurch wird Debian auch in die Lage versetzt, ganze Distributionen schnell neu zu kompilieren.

Das Wanna-Build-Team, das für Buildds verantwortlich ist, ist unter debian-wb-team@lists.debian.org erreichbar. Um festzustellen, wen Sie kontaktieren sollten (Wanna-Build-Team, Release-Team) und wie (per E-Mail, BTS), sei auf https://lists.debian.org/debian-project/2009/03/msg00096.html verwiesen.

Wenn Sie um BinNMUs oder Give-Backs (erneute Versuche nach gescheitertem Build) ersuchen, benutzen Sie bitte das unter https://release.debian.org/wanna-build.txt beschriebene Format.

5.10.4. Wenn Ihr Paket nicht portierbar ist

Einige Pakete haben immer noch Probleme mit der Erstellung und/oder Ihrer Funktion auf einigen der von Debian unterstützten Architekturen und können überhaupt nicht oder nicht in einem akzeptablen Zeitraum portiert werden. Ein Beispiel ist ein Paket, das SVGA-spezifisch ist (nur auf i386 und amd64 verfügbar) oder andere Hardware-spezifische Funktionen benutzt, die nicht von allen Architekturen unterstützt werden.

Um zu verhindern, dass beschädigte Pakete in das Archiv hochgeladen werden und Buildd-Zeit vergeuden, müssen Sie ein paar Dinge tun:

• Stellen Sie zuerst sicher, dass das Erstellen Ihres Pakets auf Architekturen, die es nicht unterstützt fehlschlägt. Es gibt mehrere Möglichkeiten dies zu bewirken. Der bevorzugte Weg ist es, während des Erstellens eine kleine Test-Suite zu verwenden, die die Funktionalität prüft und fehlschlägt, wenn es nicht funktioniert. Dies ist sowieso eine gute Idee, da es (einige) schadhafte Uploads auf allen Architekturen verhindert und außerdem ermöglicht, das Paket zu erstellen, sobald die benötigte Funktionalität verfügbar ist.

  Zusätzlich sollten Sie in debian/control den architecture-Wert any in eine Liste der unterstützten Architekturen ändern, falls Sie glauben, die Liste der unterstützten Architekturen sei ziemlich gleichbleibend. Auf diese Art wird das Erstellen ebenfalls fehlschlagen und dies einem menschlichen Leser ohne tatsächliche Versuche angezeigt.

• Um zu verhindern, dass Autobuilder unnötig versuchen, Ihr Paket zu erstellen, muss es in Packages-arch-specific enthalten sein, einer Liste, die vom wanna-build-Skript benutzt wird. Die aktuelle Version ist unter https://wiki.debian.org/PackagesArchSpecific verfügbar. Bitte lesen Sie den Anfang der Datei, wer wegen eventueller Änderungen kontaktiert werden sollte.

Bitte beachten Sie, dass es nicht ausreicht, Ihr Paket nur zu Packages-arch-specific hinzuzufügen, ohne dafür zu sorgen, dass das Erstellen auf nicht unterstützten Architekturen fehlschlägt: Ein Portierer oder jemand anderes, der versucht, Ihr Paket zu erstellen, könnte Ihr Paket fälschlicherweise hochladen, ohne zu bemerken, dass es nicht funktioniert. Wenn in der Vergangenheit Binärpakete für nicht unterstützte Architekturen hochgeladen wurden, bitten Sie um deren Entfernung, indem Sie einen Fehlerbericht gegen ftp.debian.org einreichen.

5.10.5. Unfreie Pakete als automatisch erstellbar kennzeichnen

Standardmäßig werden Pakete aus dem Bereich non-free und non-free-firmware nicht durch das Autobuilder-Netzwerk gebaut (meistens, weil die Lizenz der Pakete dem entgegen stehen könnte). Damit dort ein solches Paket dennoch gebaut wird, müssen Sie die folgenden Schritte durchführen:

1. Prüfen, ob es rechtlich erlaubt und technisch möglich ist, das Paket automatisch zu bauen;

2. XS-Autobuild: yes zu den Kopfzeilen von debian/control hinzufügen;

3. Eine E-Mail an non-free@release.debian.org senden und erklären, warum das Paket rechtlich und technisch automatisch gebaut werden kann.

5.11. Non-Maintainer Uploads (NMUs)

Jedes Paket hat einen oder mehrere Betreuer. Normalerweise sind das Leute, die daran arbeiten und neue Versionen des Pakets hochladen. In einigen Situationen ist es nützlich, dass auch andere Entwickler neue Versionen hochladen können. Zum Beispiel, falls sie einen Fehler in einem Paket beheben möchten, das sie nicht betreuen, oder wenn der Betreuer Hilfe benötigt, um auf Probleme zu antworten. Solche Uploads werden Non-Maintainer Uploads (NMU) genannt.

5.11.1. Wann und wie ein NMU durchgeführt wird

Beachten Sie die folgenden Fragen, bevor Sie einen NMU durchführen:

• Haben Sie den NMU darauf abgestimmt, dass es dem Paketbetreuer hilft? Da es Meinungsverschiedenheiten darüber geben könnte, bei was der Paketbetreuer tatsächlich Hilfe benötigt und wobei nicht, existiert die DELAYED-Warteschlange. Sie gibt dem Paketbetreuer Zeit, um zu reagieren und hat den positiven Nebeneffekt, dass unabhängige Überprüfungen des NMU-Diffs möglich sind.

• Behebt Ihr NMU wirklich Fehler? ("Fehler" umfasst jede Art von Fehlern, z.B. "wishlist"-Fehler zum Paketieren einer neuen Version der Originalautoren, es sollte jedoch Rücksicht darauf genommen werden, die Auswirkungen für den Paketbetreuer möglichst gering zu halten.) Beheben kosmetischer Probleme oder Ändern des Paketierungsstils (z.B. von CDBS auf DH umstellen) ist in NMUs nicht erwünscht.

• Haben Sie dem Paketbetreuer genug Zeit gegeben? Wann wurde der Fehler an das BTS gemeldet? Es ist nicht unüblich, für eine oder zwei Wochen beschäftigt zu sein. Ist der Fehler so schwer, dass er jetzt sofort behoben werden muss oder kann er noch ein paar Tage warten?

• Wie überzeugt sind Sie von Ihren Änderungen? Bitte erinnern Sie sich an den hippokratischen Eid: "Verursachen Sie vor allem keinen Schaden". Es ist besser, ein Paket mit einem offenen schweren Fehler zu belassen, als einen nicht funktionierenden Patch darauf anzuwenden oder einen, das den Fehler versteckt, anstatt Ihn zu beheben. Falls Sie nicht 100% sicher sind, was Sie getan haben, könnte es eine gute Idee sein, den Rat anderer zu suchen. Vergessen Sie nicht, das viele Leute sauer sind, wenn Ihr NMU etwas kaputt macht.

• Haben Sie Ihre Absicht, einen NMU durchzuführen, zumindest im BTS klar ausgedrückt? Falls dies zu keinen Rückmeldungen führte, ist es außerdem ratsam, zu versuchen, den Paketbetreuer auf andere Arten zu kontaktieren (private E-Mail, IRC).

• Haben Sie versucht, den Betreuer zu kontaktieren, falls er normalerweise aktiv und zugänglich ist? Im Allgemeinen sollte es als wünschenswert erachtet werden, dass sich Betreuer selbst um ein Problem kümmern und dass sie die Möglichkeit haben, Ihren Patch zu überprüfen und zu korrigieren, da sie potentielle Probleme kennen sollten, die demjenigen fehlen könnten, der ein NMU durchführt. Die Zeit wird meist besser investiert, wenn dem Betreuer die Gelegenheit gegeben wird, eine Fehlerbehebung selbst hochzuladen.

Wenn Sie einen NMU durchführen, sollten Sie zuerst dafür sorgen, dass Ihre Absicht klar ist, einen NMU durchzuführen. Dann müssen Sie einen Patch mit den Unterschieden zwischen dem aktuellen Paket und dem geplanten NMU an das BTS senden. Das Skript nmudiff im Paket devscripts könnte hilfreich sein.

Während Sie den Patch vorbereiten, sollten Sie sich über die paketspezifischen Verfahren bewusst sein, die der Betreuer möglicherweise benutzt. Diese einzubeziehen verringert dessen Aufwand, Ihre Änderungen im normalen Arbeitsablauf des Pakets zu integrieren und erhöht daher die Wahrscheinlichkeit, dass dies auch geschieht. Paket spezifische Methoden sind in debian/README.source beschrieben.

Sofern Sie keinen wichtigen Grund haben, dies nicht zu tun, müssen Sie dem Paketbetreuer Zeit zum Reagieren geben (zum Beispiel durch Hochladen in die DELAYED-Warteschlange). Hier sind einige empfohlene Werte für solche Wartezeiten:

• Der Upload behebt nur veröffentlichungskritische Fehler, die älter als sieben Tage sind, ohne Betreueraktivität beim Fehler für sieben Tage und ohne Hinweis, dass eine Fehlerbehebung im Gang ist: 0 Tage

• Upload, der nur veröffentlichungskritische Fehler behebt, die älter als sieben Tage sind: zwei Tage

• Upload, der nur veröffentlichungskritische Fehler und Fehler mit Schweregrad "important" behebt: fünf Tage

• Andere NMUs: zehn Tage

Diese Verzögerungen sind nur Beispiele. In manchen Fällen, wie bei Uploads, die Sicherheitsprobleme beheben, oder bei der Behebung belangloser Fehler, die einen Übergang blockieren, ist es wünschenswert, dass ein korrigiertes Paket Unstable eher erreicht.

Manchmal entscheiden Veröffentlichungsverwalter, NMUs mit kürzeren Verzögerungen für eine Untermenge von Fehlern zu erlauben (z.B. veröffentlichungskritische Fehler, die älter als sieben Tage sind). Außerdem führen manche Paketbetreuer sich selbst in der Liste LowThresholdNmu (niedrige Schwellwerte für NMUs) auf und akzeptieren, dass NMUs ohne Verzögerung hochgeladen werden. Aber sogar in diesen Fällen ist es immer noch ratsam, dem Betreuer ein paar Tage Zeit zum Reagieren zu geben, bevor Sie etwas hochladen, insbesondere wenn der Patch vorher nicht im BTS verfügbar war oder falls Sie wissen, dass der Paketbetreuer allgemein aktiv ist.

Nachdem Sie einen NMU hochgeladen haben, sind Sie für mögliche Probleme verantwortlich, die Sie möglicherweise eingeleitet haben. Sie müssen das Paket im Auge behalten (ein gute Möglichkeit dafür ist, das Paket im PTS zu abonnieren ).

Dies ist keine Lizenz, rücksichtslos NMUs durchzuführen. Falls Sie einen NMU auf den Weg bringen, während klar ist, dass die Betreuer aktiv sind und einen Patch zeitnah anerkennen würden oder falls Sie die Empfehlungen dieses Dokuments ignorieren, könnte Ihr Upload zu einem Konflikt mit dem Betreuer führen. Sie sollten immer darauf vorbereitet sein, im Nachhinein für den von Ihnen durchgeführten NMU aus eigener Kraft einstehen zu können.

5.11.2. NMUs und debian/changelog

Genauso wie bei jedem anderen (Quell-) Upload muss bei NMUs ein Eintrag in debian/changelog hinzufügt werden, der mitteilt, was mit diesem Upload geändert wurde. Die erste Zeile muss explizit erwähnen, dass dieser Upload ein NMU ist, z.B:

* Non-maintainer upload.

Die Möglichkeiten der Versionsvergabe für NMUs unterscheidet sich bei nativen und nicht nativen Paketen.

Falls es sich um ein natives Paket (ohne Debian-Revision in der Versionsnummer) handelt, muss die Versionsnummer die des letzten Betreuer-Uploads plus +nmuX sein, wobei X ein Zähler ist, der bei 1 beginnt. Falls der letzte Upload auch ein NMU war, wird der Zähler erhöht. Wenn beispielsweise die aktuelle Version 1.5 ist, dann hätte der NMU die Version 1.5+nmu1.

Falls es sich um kein natives Paket handelt, sollten Sie eine untergeordnete Versionsnummer zum Debian-Revisionsteil der Versionsnummer hinzufügen (der Teil nach dem letzten Bindestrich). Diese zusätzliche Zahl muss bei 1 anfangen. Wenn zum Beispiel die aktuelle Version 1.5-2 ist, dann würde ein NMU die Version 1.5-2.1 erhalten. Falls eine neue Originalversion im NMU paketiert wird, wird die Debian-Revision auf 0 gesetzt, zum Beispiel 1.6-0.1.

In beiden Fällen sollte der Zähler erhöht werden, falls der letzte Upload auch ein NMU war. Wenn zum Beispiel die letzte Version 1.5+nmu3 war (ein natives Paket, für das bereits ein NMU durchgeführt wurde), würde der NMU die Version 1.5+nmu4 erhalten.

Es wird ein spezielles Schema der Versionsvergabe benötigt, um zu verhindern, dass die Arbeit des Betreuers unterbrochen wird, da die Benutzung einer Ganzzahl für die Debian-Revision einen potentiellen Konflikt mit einem Betreuer-Upload hervorruft, der bereits zur Zeit des NMUs vorbereitet wird oder sogar in der Ftp-Warteschlange NEW ist. Es hat außerdem den Vorteil, dass es optisch klar erkennbar ist, wenn ein Paket im Archiv nicht vom offiziellen Betreuer stammt.

Falls Sie ein Paket nach Testing oder Stable hochladen, müssen Sie manchmal den Versionsnummernbaum "verzweigen". Dies ist zum Beispiel der Fall beim Hochladen von Sicherheitsaktualisierungen. Dazu sollte eine Version der Form +debXuY benutzt werden, wobei X die Major-Release-Nummer und Y eine fortlaufende, bei 1 beginnende Nummer ist. Während zum Beispiel bookworm (Debian 12) Stable ist, hätte ein Sicherheits-NMU für Stable für ein Paket mit der Version 1.5-3 die Version 1.5-3+deb12u1, während ein Sicherheits-NMU für trixie die Version 1.5-3+deb13u1 erhalten würde.

5.11.3. Benutzung der Warteschlange DELAYED/

Nachdem Sie um Erlaubnis ersucht haben, einen NMU durchzuführen, ist es ineffizient, auf eine Antwort zu warten, da es für denjenigen, der den NMU durchführt, einen Kontextwechsel zurück zu diesem Thema erfordert. Die Warteschlange DELAYED (siehe Verzögerte Uploads) ermöglicht es einem Entwickler, einen NMU und alle nötigen Aufgaben gleichzeitig durchzuführen. Anstatt zum Beispiel dem Betreuer mitzuteilen, dass Sie das aktualisierte Paket in sieben Tagen hochladen werden, sollten Sie das Paket nach DELAYED/7 hochladen und dem Betreuer mitteilen, dass er sieben Tage Zeit hat, um zu reagieren. Während dieser Zeit kann der Betreuer Sie bitten, den Upload etwas länger aufzuschieben oder Ihren Upload abzubrechen.

Ein Upload kann durch dcut abgebrochen werden. Falls Sie foo_1.2-1.1_all.changes zu einer DELAYED-Queue hochgeladen haben, dann können Sie dcut cancel foo_1.2-1.1_all.changes verwenden, um den Upload abzubrechen. Die .changes-Datei muss hierzu nicht mehr lokal vorliegen, da Sie dcut angewiesen haben, eine Kommandodatei hochzuladen, durch die eine entfernt liegende Datei gelöscht werden soll. Der Name der .changes-Datei ist derselbe, der auch beim Upload gesendet worden ist.

Die Warteschlange DELAYED sollte nicht benutzt werden, um zusätzlichen Druck auf den Paketbetreuer auszuüben. Es ist besonders wichtig, dass Sie erreichbar sind, um die Verzögerung des Uploads abzubrechen, bevor die Zeit abläuft, da der Betreuer den Upload nicht selbst abbrechen kann.

Falls Sie einen NMU nach DELAYED durchführen und der Betreuer das Paket vor Ablauf der Verzögerung aktualisiert, wird Ihr Upload abgelehnt, da bereits eine neuere Version im Archiv verfügbar ist. Idealerweise achtet der Betreuer darauf, dass er die von Ihnen vorgeschlagenen Änderungen (oder zumindest eine Lösung für die Probleme, die sie behandeln) in diesen Upload einfließen lässt.

5.11.4. NMUs aus Sicht des Paketbetreuers

Wenn jemand einen NMU Ihres Pakets durchführt, bedeutet dies, dass er Ihnen helfen möchte, es in einem guten Zustand zu halten. Dies beschert den Anwendern schneller korrigierte Pakete. Sie könnten überlegen, ob Sie denjenigen, der den NMU durchführte, fragen möchten ob er Mitbetreuer des Pakets werden will. Der Erhalt eines NMUs für ein Paket ist keine schlechte Sache, es bedeutet nur, dass das Paket interessant genug ist, dass andere Leute daran arbeiten.

Um einen NMU anzuerkennen, schließen Sie dessen Änderungen und Änderungsprotokolleinträge in Ihren nächsten Upload ein. Falls Sie den NMU nicht anerkennen, schließen Sie den Änderungsprotokolleintrag des NMUs in Ihr Änderungsprotokoll ein, die Fehler bleiben im BTS geschlossen, werden aber als Ihre Betreuerversion des Pakets betreffend aufgeführt.

Wenn Sie jemals einen NMU zurücksetzen müssen, der eine neuere Upstreamversion paketiert hat, dann sollten Sie eine "Fake" Upstreamversion wie AKTUELL+reallyVORHERIGE benutzen bis die neueste Version erneut hochgeladen werden kann. Weitere Informationen finden Sie unter https://www.debian.org/doc/debian-policy/ch-controlfields.html#epochs-should-be-used-sparingly.

5.11.5. Quell-NMUs gegenüber rein binären NMUs (binNMUs)

Der vollständige Name eines NMUs ist Quell-NMU. Es gibt auch einen anderen Typ, der rein binärer NMU oder binNMU genannt wird. Ein binNMU ist ebenfalls ein Paket-Upload durch jemand anderes als den Paketbetreuer. Er ist jedoch rein binär.

Wenn eine Bibliothek (oder andere Abhängigkeit) aktualisiert wird, könnte es notwendig sein, das Paket neu zu erstellen. Da keine Änderungen am Quellcode nötig sind, wird das gleiche Quellpaket benutzt.

BinNMUs werden üblicherweise auf Buildds durch Wanna-Build ausgelöst. debian/changelog wird ein Eintrag hinzugefügt, der erklärt warum der Upload nötig war und die Versionsnummer wird, wie in Neu kompilieren oder rein binärer NMU beschrieben, erhöht. Dieser Eintrag sollte nicht im nächsten Upload enthalten sein.

Buildds laden Pakete für ihre Architektur als rein binäre Uploads in das Archiv hoch. Genaugenomen sind dies die binNMUs. Sie werden jedoch normalerweise nicht als NMU bezeichnet und fügen debian/changelog keinen Eintrag hinzu.

5.11.6. NMUs gegenüber QS-Uploads

NMUs sind Uploads von Paketen durch jemand anderes als den ihnen zugewiesenen Betreuer. Es gibt noch einen anderen Upload-Typ bei dem das hochgeladene Paket nicht dem Uploader gehört: QA-Uploads. QA-Uploads sind Uploads für verwaiste Pakete.

QS-Uploads sind normalen Betreuer-Uploads sehr ähnlich: Diese können alles korrigieren, sogar kleine Probleme. Die Versionsnummerierung ist normal und es sind keine verzögerten Uploads nötig. Der Unterschied besteht darin, dass Sie nicht als Maintainer oder Uploader des Pakets aufgeführt werden. Außerdem hat der Änderungsprotokolleintrag eines QS-Uploads eine spezielle erste Zeile:

* QA upload.

Falls Sie einen NMU durchführen möchten und es so aussieht, als sei der Betreuer nicht aktiv, ist es vernünftig zu prüfen, ob das Paket verwaist ist (diese Information wird auf der Seite des Pakets im Paketverfolgungssystem "PTS" angezeigt). Beim ersten QS-Upload zu einem verwaisten Paket sollte der Betreuer auf Debian QA Group <packages@qa.debian.org> gesetzt werden. Bei verwaisten Paketen, für die noch kein QS-Upload durchgeführt wurde, ist immer noch der alte Betreuer gesetzt. Eine Liste dieser Pakete finden Sie unter https://qa.debian.org/orphaned.html.

Anstatt einen QS-Upload durchzuführen, können Sie auch erwägen, das Paket zu adoptieren, indem Sie sich selbst zum Betreuer machen. Sie benötigen von niemandem eine Erlaubnis, um ein verwaistes Paket zu adoptieren, Sie müssen sich nur selbst als Betreuer einsetzen und die neue Version hochladen (siehe Adoption eines Pakets).

5.11.7. NMUs gegenüber Team-Uploads

Manchmal korrigieren und/oder aktualisieren Sie ein Paket, weil Sie Mitglied des Paketierungs-Teams sind (das als Maintainer oder Uploader eine Mailingliste benutzt, siehe Gemeinschaftliche Verwaltung), aber Sie möchten sich selbst nicht zu den Uploaders hinzufügen, da Sie nicht planen, regulär an diesem speziellen Paket mitzuarbeiten. Falls dies mit den Leitlinien Ihres Teams in Einklang steht, können Sie einen normalen Upload durchführen, ohne direkt als Maintainer oder Uploader aufgeführt zu werden. In diesem Fall sollten Sie Ihren Änderungsprotokolleintrag mit der folgenden Zeile beginnen:

* Team upload.

5.12. Pakete bergen

"Pakete bergen" (package salvaging) ist der Prozess, mit dem man versucht, ein Paket zu retten, das zwar offiziell nicht verwaist ist, jedoch schlecht oder gar nicht gepflegt wird. Dies ist ein schwächeres und schnelleres Verfahren, als ein Paket offiziell durch die Befugnisse des MIA-Teams zu verwaisen. Das Bergen eines Pakets ist nicht als Ersatz für das MIA-Handling gedacht und unterscheidet sich insofern, als es nichts über die generelle Aktivität eines Betreuers aussagt. Stattdessen sorgt es nur für die Übertragung des Betreuerstatus eines einzelnen Pakets, wobei alle anderen Paket-, Debian-Mitgliedschafts- oder Upload-Rechte (sofern zutreffend) unberührt bleiben.

Beachten Sie, dass der Prozess nur für die aktive Übernahme der Paketbetreuung gedacht ist. Starten Sie keine Paketbergung, wenn Sie nicht beabsichtigen, das Paket für längere Zeit zu betreuen. Wenn Sie nur bestimmte Dinge reparieren wollen, aber das Paket nicht übernehmen möchten, müssen Sie den NMU-Prozess verwenden, selbst wenn das Paket für eine Bergung berechtigt wäre. Der NMU-Prozess wird in Non-Maintainer Uploads (NMUs) erläutert.

Vergessen Sie nicht: Es ist inakzeptabel, Pakete anderer zu entführen. Wenn Sie sich an diesen Bergungsprozess halten, wird er Ihnen helfen sicherzustellen, dass Ihr Vorhaben keine Entführung ist, sondern eine (legale) Bergung, und Sie können dann allen Vorwürfen der Entführung mit einer Bezugnahme auf diesen Prozess entgegentreten. Dank dieses Prozesses sollten neue Beitragende keine Angst mehr haben, Pakete zu übernehmen, die vernachlässigt oder völlig vergessen wurden.

Der Prozess ist in zwei Phasen unterteilt: In der ersten Phase stellen Sie fest, ob das fragliche Paket für den Bergungsprozess berechtigt ist. Nur wenn die Berechtigung festgestellt wurde, können Sie in die zweite Phase, das eigentliche Paketbergen, eintreten.

Für weitere Informationen, Begründungen und FAQs zur Paketbergung besuchen Sie bitte die Seite Pakete bergen im Debian-Wiki.

5.12.1. Wann es berechtigt ist, ein Paket zu bergen

Ein Paket darf geborgen werden, wenn es vom aktuellen Betreuer vernachlässigt wurde. Um festzustellen, ob ein Paket vom Betreuer wirklich vernachlässigt wurde, können die folgenden Indikatoren Hinweise darauf geben:

• NMUs, insbesondere wenn es mehrere aufeinanderfolgende NMUs gegeben hat.

• Gegen das Paket eingereichte Fehlerberichte haben keine Antwort vom Betreuer.

• Die Originalautoren haben mehrere neue Versionen veröffentlicht, aber trotz dass es einen Fehlerbericht gibt, der darum bittet, die Version zu paketieren, ist dies nicht geschehen.

• Das Paket hat Qualitätssicherungsprobleme.

Sie müssen sich selbst ein Urteil darüber bilden, ob die Kombination aus den gegebenen Faktoren eine Vernachlässigung darstellt. Wenn der Betreuer anderer Meinung ist, reicht es aus, wenn er es sagt (siehe unten). Wenn Sie sich über Ihr Urteil nicht sicher sind oder einfach auf der sicheren Seite sein wollen, gibt es einen präziseren (und konservativeren) Satz von Bedingungen auf der Paket-Bergungs-Wiki-Seite. Diese Bedingungen repräsentieren einen aktuellen Debian-Konsens bezüglich der Bergungskriterien. In jedem Fall sollten Sie Ihre Gründe erläutern, warum sie meinen, dass das Paket vernachlässigt ist, wenn Sie später den "Intent to Salvage" Fehlerbericht einreichen.

5.12.2. Wie man Pakete birgt

Wenn und nur wenn eine Paketbergung als gerechtfertigt festgestellt wurde, kann jeder potenzielle Betreuer das folgende Paketbergungsverfahren starten.

1. Öffnen Sie einen Fehler mit dem Schweregrad "important" gegen das fragliche Paket und drücken Sie in diesem Ihre Absicht aus, das Paket zu übernehmen. Dazu sollte der Titel des Fehlers mit ITS: Paketname [3] beginnen. Sie können alternativ anbieten, nur Mitbetreuer des Pakets zu werden. Wenn Sie den Fehler melden, müssen Sie alle Maintainer, Uploader und ggf. das Paketierungsteam explizit informieren, indem Sie sie zu X-Debbugs-CC hinzufügen. Falls der (die) Betreuer generell inaktiv zu sein scheinen, informieren Sie bitte das MIA-Team, indem Sie zusätzlich mia@qa.debian.org zu X-Debbugs-CC hinzufügen. Neben dem ausdrücklichen Erwähnen Ihrer Absicht zur Bergung des Paketes nehmen Sie sich bitte auch die Zeit, Ihre Einschätzung zu der Zulässigkeit des Bergens im Fehlerbericht zu dokumentieren, indem Sie beispielsweise die von Ihnen angewendeten Kriterien und zugehörige Daten anführen, um es anderen leichter zu machen, die Situation nachzuvollziehen.

2. In diesem Schritt müssen Sie warten, ob Einwände gegen die Bergung erhoben werden. Der Betreuer, jeder Mitbetreuer oder ein Mitglied des zugehörigen Paketierungsteams des betroffenen Pakets kann innerhalb von 21 Tagen mittels einer Antwort in dem Fehlerbericht öffentlich widersprechen, wodurch der Bergungsprozess beendet wird.

   Die derzeitigen Betreuer können Ihrer Absicht zur Bergung auch zustimmen, indem sie eine entsprechende öffentliche (signierte) Antwort an den Fehlerbericht senden. Sie können vorschlagen, dass Sie Mitbetreuer anstatt alleiniger Betreuers werden. Bei Team-gepflegten Paketen kann ein Mitglied des zugehörigen Teams Ihren Bergungs-Vorschlag akzeptieren, indem er eine signierte Bestätigung an den ITS-Fehlerbericht sendet. Alternativ können die bisherigen Betreuer Sie wiederum bitten, stattdessen neuer Mitbetreuer des Pakets zu werden. Das Team kann verlangen, dass Sie das Paket im Team belassen, Sie aber fragen oder Sie einladen, dem Team beizutreten. In all diesen Fällen, in denen Sie ein OK erhalten haben, fortzufahren, können Sie das neue Paket sofort als neuer (Mit-)Betreuer hochladen, ohne die DELAYED-Warteschlange, wie im nächsten Abschnitt beschrieben, verwenden zu müssen.

3. Wenn nach den 21 Tagen keine Antwort vom Betreuer, einem der Mitbetreuer oder dem Team an den Fehlerbericht gesendet wurde, können Sie die neue Version des Pakets mit einer minimalen Verzögerung von sieben Tagen in die DELAYED-Warteschlange hochladen. Sie sollten den ITS-Fehlerbericht über einen Eintrag im Changelog schließen. Sie müssen auch einen nmudiff an den Fehler senden, und dabei sicherzustellen, dass Kopien an den Betreuer und alle Mitbetreuer (einschließlich des Teams) des Pakets gesendet werden, indem Sie sie in der Mail an den Fehlerbericht unter CC eintragen.

   Während der Wartezeit in DELAYED kann der Betreuer die Bergung akzeptieren, selbst hochladen oder darum bitten, den Upload abzubrechen bzw. ihn selbst abbrechen. Die letzten beiden Fälle stoppen den Bergungsprozess, jedoch muss der Betreuer dann in dem ITS Fehlereintrag seine Aktionen begründen.

5.13. Gemeinschaftliche Verwaltung

Gemeinschaftliche Verwaltung ist ein Begriff, der die gemeinsamen Verwaltungspflichten von Debian-Paketen durch mehrere Leute beschreibt. Diese Zusammenarbeit ist fast immer eine gute Idee, da sie generell in einer höheren Qualität und einer schnelleren Fehlerbehebungszeit resultiert. Es wird dringend empfohlen, dass Pakete, die die Priorität standard haben, oder Teil vom Basis-Paketsatz sind, Mitbetreuer haben.

Generell gibt es einen Hauptbetreuer und einen oder mehrere Mitbetreuer. Der Hauptbetreuer ist die Person, deren Name im Feld Maintainer der Datei debian/control steht. Mitbetreuer sind alle anderen Betreuer. Sie werden normalerweise in der Datei debian/control im Feld Uploaders aufgeführt.

In seiner grundlegendsten Form ist der Prozess, neue Mitbetreuer hinzuzufügen ziemlich einfach:

• Richten Sie den Co-Maintainer mit Zugriff auf die Quellen ein, aus denen Sie das Paket erstellen. Im Allgemeinen bedeutet dies, dass Sie ein netzwerkfähiges Versionskontrollsystem wie Git verwenden. Salsa (siehe salsa.debian.org: Git Repositorys und kollaborative Entwicklungsplattform) bietet unter anderem Git-Repositories und andere kollaborative Werkzeuge.

• Fügen Sie im Feld Uploaders im ersten Absatz der Datei debian/control den korrekten Namen und die Adresse des Mitbetreuers ein.

  Uploaders: John Buzz <jbuzz@debian.org>, Adam Rex <arex@debian.org>
  

• Wird das PTS (Das Debian-Paketverfolgungssystem) benutzt, sollten sich die Mitbetreuer selbst für das entsprechende Quellpaket einschreiben.

Eine andere Form der gemeinschaftlichen Verwaltung stellt die Team-Verwaltung dar. Diese wird empfohlen, falls Sie mehrere Pakete mit der gleichen Entwicklergruppe verwalten. In diesem Fall müssen die Felder Maintainer und Uploaders jedes Pakets mit Vorsicht verwaltet werden. Es wird empfohlen, eines der beiden folgenden Schemen auszuwählen:

1. Setzen Sie den Hauptverantwortlichen für das Paket in das Feld Maintainer ein. In Uploaders werden die Adresse der Mailingliste und die Team-Mitglieder, die sich um das Paket kümmern, eingetragen.

2. Setzen Sie die Adresse der Mailingliste in das Feld Maintainer ein. Im Feld Uploaders werden die Team-Mitglieder eingetragen, die sich um das Paket kümmern. In diesem Fall müssen Sie sicherstellen, dass die Mailingliste Fehlerberichte ohne menschliches Eingreifen akzeptiert (wie Moderation für Nicht-Abonnenten).

Es ist auf jeden Fall eine schlechte Idee, automatisch alle Team-Mitglieder in das Feld Uploaders einzutragen. Es überfüllt die Paketübersicht des Entwicklers (siehe Paketübersicht des Entwicklers) mit Paketen, um die sich nicht wirklich jemand kümmert und erweckt den falschen Eindruck einer guten Betreuung. Aus dem gleichen Grund müssen sich Team-Mitglieder nicht selbst im Feld Uploaders hinzufügen, nur weil sie das Paket einmal hochgeladen haben. Sie können einen Team-Upload durchführen (siehe NMUs gegenüber Team-Uploads). Im umgekehrten Fall ist es eine schlechte Idee, ein Paket nur mit der Adresse der Mailingliste im Feld Maintainer und ohne einen Eintrag in Uploaders zu belassen.

5.14. Die Distribution Testing

5.14.1. Grundlagen

Pakete werden üblicherweise in der Distribution Testing installiert, nachdem sie in Unstable gewissen Tests unterzogen wurden.

Sie müssen auf allen Architekturen synchron sein und dürfen keine Abhängigkeiten haben, die sie nicht installierbar machen. Außerdem dürfen sie zum Zeitpunkt, an dem sie in Testing installiert werden, keine bekannten veröffentlichungskritischen Fehler haben. Auf diese Art sollte Testing immer ein potentieller Veröffentlichungskandidat sein. Bitte lesen Sie das Folgende, um weitere Einzelheiten zu erfahren.

5.14.2. Aktualisierungen von Unstable

Die Skripte, die die Distribution Testing aktualisieren, werden zweimal täglich ausgeführt, gleich nach der Installation der aktualisierten Pakete. Diese Skripte werden britney genannt. Sie generieren die Packages-Dateien für die Distribution Testing, aber dabei versuchen diese entsprechend clever zu agieren, sie versuchen jede Unstimmigkeit zu vermeiden und nur fehlerfreie Pakete zu benutzen.

Die Aufnahme eines Pakets von Unstable ist von folgendem abhängig:

• Das Paket muss in unstable für eine bestimmte Anzahl an Tagen verfügbar sein (Siehe Auswahl Dringlichkeit des Uploads). Bitte beachten Sie, dass die Dringlichkeit „sticky“ ist, was bedeutet, dass die höchste Dringlichkeitsstufe, die seit dem vorherigen Übergang zu testing` hochgeladen wurde, berücksichtigt wird.

• Es darf keine veröffentlichungskritischen Fehler haben (veröffentlichungskritische Fehler betreffend die in Unstable verfügbare Version, aber nicht die in Testing).

• Es muss auf allen Architekturen verfügbar sein auf denen es vorher in Unstable erstellt wurde. Um diese Information zu prüfen, könnte Das Hilfswerkzeug dak ls von Interesse sein.

• Es darf keine Abhängigkeiten von Paketen zerstören, die bereits in Testing verfügbar sind.

• Die Pakete, von denen es abhängt, müssen entweder in Testing verfügbar sein oder sie müssen zur gleichen Zeit in Testing akzeptiert werden (und das werden sie, falls sie alle nötigen Kriterien erfüllen).

• Die aktuelle Phase des Projekts, d.h. zum Beispiel, dass automatische Übergänge während des Freeze der Distribution Testing ausgesetzt werden.

Um herauszufinden ob ein Paket den Übergang nach Testing erfolgreich durchläuft oder nicht, schauen Sie in die Ausgabe des Testing-Skripts auf der Web-Seite Debian "Testing"-Distribution oder benutzen Sie das Programm grep-excuses aus dem Paket devscripts. Dieses Hilfswerkzeug kann einfach in einer crontab 5 benutzt werden, um sich selbst auf dem aktuellen Stand über den Fortschritt des Pakets nach Testing zu informieren.

Die Datei update_excuses gibt nicht immer den genauen Grund an, warum ein Paket abgelehnt wurde. Sie können es selbst herausfinden, indem Sie schauen, was durch die Aufnahme des Pakets zerstört werden würde. Die Web-Seite Debian "Testing"-Distribution stellt einige weitere Informationen über die üblichen Probleme bereit, die derartigen Ärger verursachen.

Manchmal errreichen einige Pakete Testing niemals, da die Zusammensetzung wechselseitiger Beziehungen zu kompliziert ist und durch das Skript nicht aufgelöst werden können. Im Folgenden finden Sie Einzelheiten.

Einige weitere Abhängigkeitsanalysen werden unter https://release.debian.org/migration/ dargestellt — aber seien Sie gewarnt, diese Seite zeigt auch Build-Abhängigkeiten, die von Britney nicht berücksichtigt werden.

5.14.2.1. Veraltet

Für das Testing Migrationsskript bedeutet veraltet: Es gibt verschiedene Versionen in``Unstable`` für die Release-Architekturen (mit Ausnahme der Architekturen in outofsync_arches, outofsync_arches ist eine Liste von Architekturen, die nicht mithalten ist (in britney.py), derzeit aber leer ist). Veraltet hat überhaupt nichts mit den Architekturen zu tun, die dieses Paket in Testing hat.

Sehen Sie sich dieses Beispiel an:

	alpha	arm
testing	1	-
unstable	1	2

Das Paket ist auf alpha in Unstable veraltet und wird nicht nach Testing gelangen. Das Paket zu entfernen würde überhaupt nicht helfen. Das Paket ist immer noch auf alpha veraltet und wird nicht nach Testing gelangen.

Falls FTP-Master jedoch ein Paket in Unstable entfernt (hier auf arm):

	alpha	arm	hurd-i386
testing	1	1	-
unstable	2	-	1

In diesem Fall ist das Paket auf allen Architekturen in Unstable aktuell (und das zusätzliche hurd-i386 tut nichts zur Sache, da es keine Release-Architektur ist).

Manchmal kommt die Frage auf, ob es möglich ist, Pakete aufzunehmen, die noch nicht auf allen Architekturen erstellt wurden: Nein. Einfach nur nein. (Außer Sie betreuen glibc oder ähnlich).

5.14.2.2. Entfernen aus Testing

Manchmal wird ein Paket entfernt, um einem anderen Paket die Aufnahme zu gewähren. Dies geschieht nur, um einem anderen Paket die Aufnahme zu gewähren, falls dies sinnvoll ist. Angenommen, a könnte z.B. nicht mit der neuen Version von b installiert werden, dann könnte a entfernt werden, um b die Aufnahme zu ermöglichen.

Natürlich gibt es einen anderen Grund, ein Paket aus Testing zu entfernen. Es ist einfach zu fehlerhaft (und ein einfacher veröffentlichungskritischer Fehler reicht dafür aus).

Wenn ein Paket außerdem aus Unstable entfernt wurde und kein Paket in Testing mehr davon abhängt, dann wird es automatisch entfernt.

5.14.2.3. Zirkulare Abhängigkeiten

Eine Situation mit der Britney nicht gut klar kommt ist, wenn Paket a von einer neuen Version des Pakets b abhängt und umgekehrt.

Ein Beispiel hierfür:

	testing	unstable
a	1; depends: b=1	2; depends: b=2
b	1; depends: a=1	2; depends: a=2

Weder Paket a noch Paket b wird für die Aktualisierung berücksichtigt.

Aktuell erfordert dies einige manuelle Eingriffe des Release-Teams. Bitte kontaktieren Sie es per E-Mail an debian-release@lists.debian.org, falls dies bei einem Ihrer Pakete auftritt.

5.14.2.4. Beeinflussen eines Pakets in Testing

Im Allgemeinen gibt es nichts, was vom aktuellen Status eines Pakets in Testing von Bedeutung für den Übergang der nächsten Version von Unstable zu Testing ist, mit zwei Ausnahmen: Wenn die Anzahl der Menge an RC-Fehlern des Pakets verkleinert wird, kann das Paket migrieren auch wenn es noch veröffentlichungskritische Fehler hat. Die zweite Ausnahme ist die wenn die Version des Pakets in Testing auf den verschiedenen Architekturen nicht synchron ist. Dann kann jede Architektur auf die Version des Quellpakets aktualisiert werden. Dies kann jedoch nur geschehen, wenn das Paket zuvor zwangsmäßig migriert wurden ist, die Architektur in der Datei outofsync_arches befindet oder während der Migration nach Testing überhaupt kein Binärpaket dieser Architektur in Unstable vorhanden war.

Zusammengefasst heißt das: Der einzige Einfluss eines Pakets, das sich in Testing befindet, auf eine neue Version des gleichen Pakets besteht darin, dass die neue Version leichter aufgenommen werden kann.

5.14.2.5. Einzelheiten

Falls Sie die Einzelheiten interessieren, hier ein paar Erklärungen wie Britney funktioniert:

Die Pakete werden betrachtet, um festzulegen, ob Sie gültige Kandidaten sind. Daraus werden die update excuses (Gründe für eine Nicht-Aktualisierung) erzeugt. Die häufigsten Gründe warum ein Paket nicht berücksichtigt wird lauten: zu neu, zu viele veröffentlichungskritische Fehler oder auf einigen Architekturen veraltet. Für diesen Teil von Britney verfügen die Veröffentlichungsverwalter über Druckmittel verschiedener Stärke (Hinweise genannt, siehe unten), um eine Berücksichtigung des Pakets durch Britney zu erzwingen.

Nun kommt der komplexere Teil: Britney versucht, Testing mit den gültigen Kandidaten zu aktualisieren. Dazu versucht Britney jeden gültigen Kandidaten zur Distribution Testing hinzuzufügen. Falls die Zahl nicht installierbarer Pakete in Testing sich nicht erhöht, wird das Paket akzeptiert. Ab diesem Zeitpunkt wird das Paket als Teil von Testing betrachtet, so dass alle anschließenden Tests zur Installierbarkeit dieses Paket einbeziehen. Hinweise des Release-Teams werden, abhängig vom genauen Typ, vor diesem Hauptdurchlauf verarbeitet.

Falls Sie weitere Einzelheiten suchen, können Sie unter https://release.debian.org/britney/update_output/ nachsehen.

Die Hinweise sind unter https://release.debian.org/britney/hints/ verfügbar. Dort finden Sie auch die Beschreibung dazu. Mit den Hinweisen kann das Debian Release-Team Pakete blockieren oder entsperren, Paketmigration nach Testing vereinfachen oder auch erzwingen, Pakete aus Testing entfernen, Uploads genehmigen für Direkte Aktualisierungen für Testing oder die Dringlichkeit überschreiben.

5.14.3. Direkte Aktualisierungen für Testing

Die Distribution Testing wird, den genannten Regeln folgend, mit Paketen aus Unstable gespeist. In einigen Fällen ist es jedoch nötig, Pakete hochzuladen, die nur für Testing erstellt wurden. Dafür empfiehlt es sich, nach testing-proposed-updates hochzuladen.

Merken Sie sich, dass dorthin hochgeladene Pakete nicht automatisch verarbeitet werden, sie müssen erst durch die Hand des Veröffentlichungsverwalters gehen. Daher sollten sie besser über einen triftigen Grund verfügen, dorthin hochzuladen. Um zu erfahren, was in den Augen der Veröffentlichungsverwalter ein triftiger Grund ist, sollten sie die Anweisungen lesen, die diese reglemäßig auf debian-devel-announce@lists.debian.org verteilen.

Sie sollten nicht auf testing-proposed-updates hochladen, wenn Sie Ihre Pakete über Unstable aktualisieren können. Wenn Sie dies nicht können (z. B. weil Sie eine neuere Entwicklungsversion in Unstable haben), dann können Sie diese Option verwenden. Selbst wenn ein Paket eingefroren ist, sind Aktualisierungen über Unstable möglich, wenn beim Hochladen über Unstable keine neuen Abhängigkeiten entstehen.

Versionsnummern werden üblicherweise durch Anhängen von +debXuY ausgewählt, wobei X die Major-Release-Nummer von Debian und Y eine bei 1 beginnende Nummer ist, die hochgezählt wird, z.B. 1:2.4.3-4+deb12u1.

Bitte stellen Sie sicher, dass Sie alle folgenden Punkte für Ihrem Upload beachtet haben:

• Vergewissern Sie sich, dass Ihr Paket wirklich testing-proposed-updates durchlaufen muss und nicht über Unstable gehen kann.

• Achten Sie darauf, dass Sie nur die kleinstmögliche Menge von Änderungen eingefügt haben.

• Sorgen Sie dafür, dass das Änderungsprotokoll eine entsprechende Erklärung enthält.

• Überzeugen Sie sich, dass Sie den Codenamen der Veröffentlichungen von Testing (z.B. trixie) als Zieldistribution eingetragen haben.

• Prüfen Sie nach, ob Sie Ihr Paket in Testing und nicht in Unstable getestet haben.

• Gehen sie sicher, dass Ihre Versionsnummer höher als die Version in Testing und testing-proposed-updates ist und niedriger als in Unstable.

• Fragen Sie im Vorfeld die Veröffentlichungsmanager nach einer Erlaubnis.

• Nach dem Hochladen und erfolgreichen Erstellen auf allen Plattformen kontaktieren Sie das Release-Team unter debian-release@lists.debian.org und ersuchen Sie es um Genehmigung Ihres Uploads.

5.14.4. Häufig gestellte Fragen

5.14.4.1. Was sind veröffentlichungskritische Fehler und wie werden diese gezählt?

Alle Fehler mit einem höheren Schweregrad werden standardmäßig als veröffentlichungskritisch angesehen. Aktuell sind dies Fehler der Schweregrade critical, grave und serious.

Von solchen Fehlern wird angenommen, dass sie einen Einfluss darauf haben, ob das Paket mit dem Stable-Release von Debian veröffentlicht wird: Im Allgemeinen würde ein Paket, das offene veröffentlichungskritische Fehler hat, nicht nach Testing gelangen und demzufolge nicht in Stable veröffentlicht werden.

Als Unstable-Fehleranzahl werden alle veröffentlichungskritischen Fehler gezählt, die für eine Paket-/Versions-Kombination markiert sind, welche in Unstable für eine Release-Architektur verfügbar ist. Die Fehleranzahl in Testing ist analog dazu definiert.

5.14.4.2. Wie kann das Installieren eines Pakets in Testing andere Pakete möglicherweise beschädigen?

Die Struktur der Distributionsarchive ist so aufgebaut, dass Sie nur eine Version eines Pakets enthalten kann. Ein Paket wird durch seinen Namen definiert. Wenn also das Quellpaket acmefoo zusammen mit seinen Binärpaketen acme-foo-bin, acme-bar-bin, libacme-foo1 und libacme-foo-dev nach Testing installiert wird, wird die alte Version entfernt.

Die alte Version könnte jedoch ein Binärpaket mit einem alten Soname einer Bibliothek bereitstellen, wie libacme-foo0. Das Entfernen der alten acmefoo wird libacme-foo0 entfernen, was alle Pakete beschädigt, die davon abhängen.

Offenbar betrifft dies hauptsächlich Pakete, die sich ändernde Zusammenstellungen von Binärpaketen in unterschiedlichen Versionen bereitstellen (wiederum hauptsächlich Bibliotheken). Es wird jedoch außerdem Pakete betreffen, deren Versionsabhängigkeiten über die Varianten ==, <= oder << deklariert wurden.

Wenn sich die Zusammenstellung von Binärpaketen, die von einem Quellpaket bereitgestellt werden, auf diese Weise ändert, müssen alle Pakete, die von den alten Programmen abhängen, aktualisiert werden, damit sie stattdessen von den neuen Programmen abhängen. Da das Installieren eines solchen Quellpakets in Testing alle Pakete beschädigt, die in Testing davon abhängen, ist nun auf Folgendes zu achten: All die abhängigen Pakete müssen aktualisiert werden und selbst bereit zur Installation sein, so dass sie nicht beschädigt werden. Sobald alles bereit ist, ist normalerweise ein manuelles Eingreifen des Veröffentlichungsverwalters oder eines Assistenten nötig.

Falls Sie Probleme mit wie hier dargestellten komplizierten Gruppen von Paketen haben, kontaktieren Sie debian-devel@lists.debian.org oder debian-release@lists.debian.org, um Hilfe zu erhalten.

[1]

Einen Leitfaden, in welchen Bereich ein Paket gehört, finden Sie im Debian Policy Manual.

[2]

In der Vergangenheit benutzten solche NMUs die dritte Stufe im Debian-Teil der Revisionsnummer, um ihren Status als reine Neu-Kompilierung anzuzeigen. Diese Syntax war jedoch bei nativen Paketen mehrdeutig und erlaubte keine ordnungsgemäße Einordnung von reinen Neu-Kompilierungs-NMUs, Quell-NMUs und Sicherheits-NMUs im gleichen Paket. Daher wurden sie verworfen und diese neue Syntax bevorzugt.

[3]

ITS it eine Abkürzung für "Intend to Salvage", sinngemäß für "Absichtserklärung für das Bergen"

[4]

Wenn sich ein Paket jedoch noch in der Upload-Queue befindet und noch nicht nach Incomming verschoben wurde, kann es entfernt werden. (Siehe Hochladen nach ftp-master)

5.15. Das Archive von Stable Backports

5.15.1. Grundlagen

Wenn ein Paket die Distribution testing erreicht hat dann ist es für jede Person in Debian mit Upload Berechtigungen (Siehe nachstehende Infos) möglich einen Backport dieses Paketes zu bauen und nach stable-backports hoch zu laden, dies ermöglicht eine einfache Installation eines Paketes aus testing auf einem System was der stable Distribution folgt.

Man sollte eine Version eines Pakets erst dann nach stable-backports hochladen, wenn die passende Version bereits das testing Archiv erreicht hat.

5.15.2. Ausnahmen von der erst-testing Regel

Die einzige Ausnahme von der oben genannten Regel besteht, wenn es einen wichtigen Sicherheitsfix gibt, der einen schnellen Upload rechtfertigt: In einem solchen Fall besteht keine Notwendigkeit, den Upload des Sicherheitsfixes in das stable-backports Archiv zu verzögern. Es wird jedoch dringend empfohlen, das Paket zunächst in „unstable“ zu reparieren, bevor ein Fix in das stable-backports Archiv hochgeladen wird.

5.15.3. Wer kann Pakete im Stable-Backports Archiv verwalten?

Es ist nicht unbedingt Aufgabe des ursprünglichen Paketbetreuers, die stable-backports Version des Pakets zu pflegen. An sich kann dies jeder tun und man braucht dazu nicht einmal die Genehmigung des ursprünglichen Paketbetreuers. Es empfiehlt sich jedoch, sich zunächst mit dem ursprünglichen Betreuer des Pakets in Verbindung zu setzen, bevor Sie versuchen, mit der Portierung eines Pakets in stable-backports zu beginnen. Der Paketbetreuer kann den Wunsch haben selbst den Backport selbst zu tätigen, oder Ihnen helfen den Backport zu erstellen. Es ist beispielsweise nicht ungewöhnlich, einen Patch auf die instabile Version eines Pakets anzuwenden, um dessen Rückportierung zu erleichtern.

5.15.4. Wann kann man damit beginnen Pakete nach stable-backports hoch zu laden?

Ein neues stable-backports wird vor dem Freeze der nächsten stable Suite erstellt. Allerdings ist ein Hochladen dorthin bis zum Ende des Freeze-Zyklus nicht gestattet. Das stable-backports Archiv wird normalerweise einige Wochen vor der endgültigen Veröffentlichung der nächsten stable Suite geöffnet, es macht jedoch keinen Sinn etwas hoch zu laden, bis die Veröffentlichung tatsächlich erfolgt ist.

5.15.5. Wie lange muss ein Paket betreut werden wenn es nach stable-backports geladen worden ist?

Das stable-backports Archiv wird während des gesamten Lebenszyklus der Debian stable Suite zur Pflege von Fehler- und Sicherheitsprobleme betreut. Daher impliziert ein Upload auf stable-backports die Bereitschaft, das zurückportierte Paket für die Dauer der stable Suite zu betreuen, was voraussichtlich etwa drei Jahre nach der ersten Veröffentlichung sind.

Die Person, die nach Backports hochlädt, sollte sich auch für Security Fixes der zurückportierten Pakete während der Lebensdauer von „stable“ verantwortlich sehen.

Es ist zu beachten, dass stable-backports nicht Teil der LTS oder ELTA Initiative ist. Die FTP-Master von stable-backports werden das Repository stable-backports für Uploads schließen sobald stable das Ende das Lebenszyklus (EOF) erreicht hat (Z.B. wenn stable nur noch durch das LTS-Team verwaltet wird). Dadurch erfolgt keine weitere Bearbeitung von Paketen in stable-backports nach dem offiziellen Ende das Lebenszykluses der Suite stable da keine neueren Uploads mehr akzeptiert werden.

5.15.6. Wie oft sollte man ein Paket nach stable-backport hochladen?

Die Pakete in Backports sollen den Entwicklungen im Testing folgen. Daher wird erwartet, dass jede bedeutende Aktualisierung in „testing“ einen Upload in „stable-backports“ auslöst, bis das neue „stable“ Release veröffentlicht wird. Bitte portieren Sie kleinere Versionsänderungen jedoch nicht ohne für den Benutzer sichtbare Änderungen oder Fehlerbehebungen nach Backports.

5.15.7. Wie kann man mehr über das Zurückportieren erfahren?

Auf der Webseite Wie man beitragen kann können Sie mehr zu dieser Frage erfahren.

Es wird auch empfohlen die Frequently Asked Questions (FAQ) zu lesen.

6. Optimale Vorgehensweise beim Paketieren

Debians Qualität ist größtenteils den Debian-Richtlinien zu verdanken, die explizit grundlegende Anforderungen definieren, die alle Debian-Pakete erfüllen müssen. Außerdem stehen gemeinsame Erfahrungen im Paketieren aus der Vergangenheit hinter den Debian-Richtlinien. Viele sehr talentierte Leute haben großartige Werkzeuge geschaffen, Werkzeuge, die Ihnen als Debian-Betreuer helfen, ausgezeichnete Pakete zu erstellen und zu pflegen.

Dieses Kapitel stellt einige optimale Vorgehensweisen für Debian-Entwickler vor. Das alles sind lediglich Empfehlungen und keine Anforderungen oder feste Regeln. Es sind nur subjektive Hinweise, Ratschläge und Fingerzeige, die von Debian-Entwicklern gesammelt wurden. Suchen Sie sich einfach das heraus, was Ihnen am meisten zusagt.

6.1. Optimale Vorgehensweisen für debian/rules

Die folgenden Empfehlungen gelten für die Datei debian/rules. Da debian/rules den Build-Prozess steuert und die Dateien auswählt, die in das Paket gelangen (direkt oder indirekt), ist es normerweise die Datei, der die Betreuer die meiste Zeit widmen.

6.1.1. Helferskripte

Der Grund für die Benutzung von Helferskripten in debian/rules ist, dass sie den Betreuern eine gemeinsame allgemeine Logik inmitten vieler Pakete ermöglichen. Nehmen Sie zum Beispiel die Frage, wie Menü-Einträge installiert werden: Sie müssen die Datei in /usr/share/menu (oder /usr/lib/menu für ausführbare binäre Menü-Dateien, wenn nötig) ablegen und den Betreuerskripten Befehle hinzufügen, um Menü-Einträge zu registrieren bzw. ihre Registrierung zu entfernen. Dies ist eine sehr häufige Tätigkeit für Pakete. Warum sollte daher jeder Betreuer all dies für sich selbst neu schreiben und dabei möglicherweise Fehler verursachen? Außerdem, gesetzt den Fall, das Menü-Verzeichnis würde sich ändern, müsste dann jedes Paket geändert werden.

Helferskripte kümmern sich um diese Probleme. Angenommen, Sie erfüllen alle Gepflogenheiten, die das Helferskript erwartet, dann kümmert sich das Helferskript um alle Einzelheiten. Änderungen an den Richtlinien können im Helferskript erledigt werden. Dann müssen Pakete nur mit der neuen Version des Helferskripts erstellt und sonst nicht geändert werden.

Überblick über die Werkzeuge der Debian-Betreuer enthält ein paar verschiedene Helferskripte. Das gängigste und beste Helfersystem (nach Meinung von Debian) ist debhelper. Frühere Helfersysteme wie debmake waren monolithisch. Man konnte nicht einen Teil des Helferskripts herausgreifen und verwenden, den man nützlich fand, sondern musste den Helfer für alles benutzen. debhelper besteht jedoch aus mehreren getrennten kleinen dh_*-Programmen. dh_installman installiert und komprimiert zum Beispiel Handbuchseiten, dh_installmenu installiert Menü-Dateien und so weiter. Daher bietet es eine ausreichende Flexibilität, die kleinen Helferskripte dort zu benutzen, wo sie nützlich sind, in Verbindung mit handgemachten Befehlen in debian/rules.

Sie können mit debhelper beginnen, indem Sie debhelper 1 lesen und sich die Beispiele ansehen, die dem Paket beigefügt sind. dh_make aus dem Paket dh-make (siehe dh-make) kann benutzt werden, um ein einfaches Quellpaket in ein mit debhelper bearbeitetes Paket umzuwandeln. Gleichwohl sollte diese Kurzform Sie jedoch nicht davon überzeugen, dass Sie sich nicht plagen müssen, um die einzelnen dh_*-Helfer zu verstehen. Falls Sie einen Helfer benutzen möchten, müssen Sie sich die Zeit nehmen zu lernen, wie dieser Helfer benutzt wird, um zu verstehen, was er erwartet und wie er sich verhält.

6.1.2. Unterteilen Sie Ihre Patches in mehrere Dateien

Große, komplexe Pakete könnten mehrere Fehler haben, die Sie bewältigen müssen. Falls Sie mehrere Fehler direkt im Quellcode beheben und nicht sorgfältig vorgehen, kann es schwierig werden, die verschiedenen Patches, die Sie bereitgestellt haben, zu unterscheiden. Es kann ziemlich chaotisch werden, wenn Sie das Paket auf eine neue Originalversion aktualisieren müssen, die einige (aber nicht alle) Korrekturen enthält. Sie können nicht die komplette Zusammenstellung der Diffs nehmen (z.B. aus .diff.gz) und austüfteln, welcher Patch es als Einheit zurücksetzt, da Fehler im Original behoben wurden.

Glücklicherweise ist es nun mit dem Quellformat "3.0 (quilt)" möglich, die Patches getrennt zu halten, ohne debian/rules zur Einrichtung eines Patch-Systems ändern zu müssen. Patches werden in debian/patches/ gespeichert und wenn das Quellpaket entpackt wird, werden automatisch die Patches angewandt, die in debian/patches/series aufgeführt sind. Wie der Name schon sagt, können Patches mit quilt verwaltet werden.

Wenn Sie den älteren Quellcode "1.0" verwenden, ist es auch möglich, Patches zu trennen, aber es muss ein zugehöriges Patch-System verwandt werden: Die Patch-Dateien werden innerhalb der Debian-Patch-Datei (.diff.gz) mitgeliefert, normalerweise im Verzeichnis debian/. Der einzige Unterschied ist, dass sie nicht unmittelbar von dpkg-source angewandt werden, sondern von der build-Regel der Datei debian/rules durch eine Abhängigkeit in der patch-Regel. Im Gegenzug werden sie von der Regel clean durch eine Abhängigkeit zur Regel unpatch umgekehrt.

quilt ist das dafür empfohlene Werkzeug. Es erledigt alles oben beschriebene und ermöglicht außerdem die Verwaltung von Patch-Serien. Weitere Informationen finden Sie im Paket quilt.

6.1.3. Pakete mit mehreren Binärdateien

Ein einzelnes Quellpaket erstellt häufig mehrere Binärpakete, entweder um mehrere Varianten derselben Software bereitzustellen ( siehe z. B. das vim-Quellpaket) oder um mehrere kleine Pakete anstelle eines großem zu erstellen (z. B. damit der Benutzer sich nur die benötigte Teilmenge an Paketen installieren kann die der er benötigt, und dadurch auch Speicherplatz spart siehe z. B. das Quellpaket libxml2).

Der zweite Fall kann einfach in debian/rules verwaltet werden. Sie müssen nur die entsprechenden Dateien aus dem Build-Verzeichnis in die entsprechenden temporären Baumstrukturen des Pakets verschieben. Dies können Sie mit install oder dh_install aus debhelper erledigen. Sorgen Sie dafür, dass Sie die unterschiedlichen Umsetzungen der verschiedenen Pakete prüfen, um sicherzustellen, dass Sie die wechselseitigen Abhängigkeiten in debian/control richtig gesetzt haben.

Der erste Fall ist etwas schwieriger, da er mehrmaliges Neukompilieren der selben Software einschließt, aber mit unterschiedlichen Konfigurationsoptionen. Das vim-Quellpaket ist ein Beispiel dafür, wie dies mit einer handgemachten debian/rules-Datei gemacht wird.

6.2. Optimale Vorgehensweisen für debian/control

Die folgenden Vorgehensweisen sind maßgeblich für die Datei debian/control. Sie ergänzen die Richtlinien für Paketbeschreibungen.

Die Beschreibung des Pakets, wie es durch das entsprechende Feld in der Datei control definiert wird, enthält sowohl die Paketübersicht als auch die ausführliche Beschreibung des Pakets. Allgemeine Leitlinien für Paketbeschreibungen beschreibt übliche Richtlinien für beide Teile der Paketbeschreibung. Diesen folgend stellt Die Paketübersicht oder Kurzbeschreibung Richtlinien speziell für die Übersicht bereit und Die ausführliche Beschreibung enthält spezielle Richtlinien für die Beschreibung.

6.2.1. Allgemeine Leitlinien für Paketbeschreibungen

Die Paketbeschreibung sollte für den erwarteten Durchschnittsanwender geschrieben werden, der Durchschnittsperson, die das Paket benutzt und davon profitiert. Entwicklungspakete sind beispielsweise für Entwickler und können in einer technischen Sprache verfasst werden. Anwendungen für allgemeinere Zwecke, wie Editoren, sollten für Anwender mit weniger technischem Verständnis geschrieben werden.

Die Durchsicht der Paketbeschreibungen mündet in der Schlussfolgerung, dass die meisten Paketbeschreibungen technischer Natur sind, also nicht so geschrieben, dass sie für Anwender ohne technischen Hintergrund einen Sinn ergeben. Sofern Ihr Paket nicht wirklich für technikkundige Anwender gedacht ist, ist dies ein Problem.

Wie können sie für nicht technikkundige Anwender schreiben? Vermeiden Sie Fachsprache. Vermeiden Sie, sich auf Anwendungen und Rahmenwerke zu beziehen, mit denen der Anwender möglicherweise nicht vertraut ist – GNOME oder KDE sind in Ordnung, da Anwender wahrscheinlich mit diesen Begriffen vertraut sind, aber GTK vermutlich nicht. Versuchen Sie nicht irgendein Wissen vorauszusetzen, geben Sie eine Einführung.

Seien Sie objektiv. Paketbeschreibungen sind nicht der richtige Ort, um Ihr Paket anzupreisen, egal wie sehr Sie es mögen. Denken Sie daran, dass der Leser nicht die gleichen Dinge als wichtig ansieht wie Sie.

Bezüge zu Namen anderer Softwarepakete, Protokollnamen, Standards oder Spezifikationen sollten, falls sie existiert, in ihrer vorschriftsmäßigen Form verwandt werden. Benutzen Sie zum Beispiel X Window System, X11 oder X, nicht X Windows, X-Windows, or X Window. Benutzen Sie GTK, nicht GTK+ oder gtk. Benutzen Sie GNOME, nicht Gnome. Benutzen Sie PostScript, nicht Postscript oder postscript.

Falls Sie Probleme beim Verfassen Ihrer Beschreibung haben, könnten Sie sie an debian-l10n-english@lists.debian.org senden und um Rückmeldung ersuchen.

6.2.2. Die Paketübersicht oder Kurzbeschreibung

Die Richtlinie legt fest, dass die Übersichtszeile (die Kurzbeschreibung) kurz sein muss, den Paketnamen nicht wiederholen darf, aber trotzdem informativ sein muss.

Die Übersichtsfunktionen sind ein Ausdruck, der das Paket beschreibt, kein kompletter Satz, daher ist Zeichensetzung unangebracht: Es wird weder eine besondere Großschreibung noch ein abschließender Punkt benötigt. Außerdem sollten jegliche bestimmten und unbestimmten Artikel am Anfang weggelassen werden – "a", "an" oder "the". Deshalb zum Beispiel:

Package: libeg0
Description: exemplification support library

Technisch gesehen ist dies eine Nominalphrase im Gegensatz zu einer Verbalphrase. Eine gute Entscheidungsregel ist, dass es möglich sein sollte, den Paket-Namen und die Übersicht in diesem Schema zu ersetzen:

Das Paket Name stellt {ein,eine,den,einige} Übersicht zur Verfügung.

Zusammenstellungen verwandter Pakete können ein alternatives Schema benutzen, das die Übersicht in zwei Teile unterteilt, als erstes eine Beschreibung der ganzen Suite und als zweites eine Zusammenfassung der Rolle, die das Paket darin spielt:

Package: eg-tools
Description: simple exemplification system (utilities)

Package: eg-doc
Description: simple exemplification system - documentation

Diese Übersicht folgt einem geänderten Schema. Wo ein Paket "Name" die Übersicht "Suite (Rolle)" oder "Suite - Rolle" hat, sollten die Elemente so ausgedrückt werden, dass sie in dieses Schema passen:

Das Paket Name stellt {ein,eine,die} Rolle für die Suite zur Verfügung.

6.2.3. Die ausführliche Beschreibung

Die ausführliche Beschreibung ist die wichtigste für den Benutzer verfügbare Information über ein Paket, bevor er es installiert. Sie sollte alle nötigen Informationen bereitstellen, damit der Anwender entscheiden kann, ob er das Paket installieren möchte. Es ist anzunehmen, dass der Benutzer bereits die Paketübersicht gelesen hat.

Die ausführliche Beschreibung sollte aus vollständigen Sätzen bestehen.

Der erste Absatz der ausführlichen Beschreibung sollte die folgenden Fragen beantworten: Was tut das Paket? Bei welchen Aufgaben hilft es dem Anwender? Es ist wichtig, dies auf eine nicht technische Weise zu beschreiben, sogar dann, wenn die Zielgruppe des Pakets notwendigerweise einen technischen Hintergrund hat.

Lange Beschreibungen verwandter Pakete, die beispielsweise aus derselben Quelle erstellt wurden, können Absätze gemeinsam nutzen, um die Konsistenz zu erhöhen und den Arbeitsaufwand für Übersetzer zu verringern. Sie benötigen jedoch mindestens einen separaten Absatz, der die spezifische Rolle des Pakets beschreibt.

Die folgenden Absätze sollten die folgenden Fragen beantworten: Warum benötige ich als Benutzer dieses Paket? Welche anderen Funktionen bietet das Paket? Welche herausragenden Funktionen und Mängel gibt es im Vergleich zu anderen Paketen (z.B. falls Sie X benötigen, benutzen Sie Y)? Steht das Paket in einem Zusammenhang mit anderen Paketen, die nicht vom Paketmanager gehandhabt werden (z.B. ist dies der Client für den Foo-Server)?

Seien Sie vorsichtig, um Rechtschreib- und Grammatikfehler zu vermeiden. Sorgen Sie für eine Rechtschreibprüfung. Sowohl ispell als auch aspell haben spezielle Modi zur Prüfung von debian/control-Dateien:

ispell -d american -g debian/control

aspell -d en -D -c debian/control

Anwender erwarten normalerweise, dass diese Fragen in der Paketbeschreibung beantwortet werden:

• Was tut das Paket? Falls es eine Erweiterung eines anderen Pakets ist, dann sollte eines Kurzbeschreibung des Pakets, das es erweitert, hier eingefügt werden.

• Warum sollte ich dieses Paket wollen? Dies bezieht sich auf das vorhergehende, aber nicht das gleiche (dies ist ein Mail-Client. Er ist toll, schnell, hat Schnittstellen zu PGP, LDAP und IMAP, hat die Funktionen X, Y und Z).

• Falls dieses Paket nicht direkt installiert werden sollte, sondern von einem anderen Paket mitinstalliert wird, sollte dies erwähnt werden.

• Falls das Paket experimental ist oder es andere Gründe gibt, weshalb es nicht benutzt werden sollte und wenn es andere Pakete gibt, die stattdessen benutzt werden sollen, sollte dies auch hier stehen.

• Was unterscheidet dieses Paket von der Konkurrenz? Ist es eine bessere Implementierung? Mehr Funktionen? Andere Funktionen? Warum sollte die Wahl auf dieses Paket fallen?

6.2.4. Homepage der Originalautoren

Es wird empfohlen, dass Sie die URL der Homepage des Pakets in das Feld Homepage im Abschnitt Source von debian/control hinzufügen. Diese Information in die Paketbeschreibung selbst einzutragen, wird als nicht erwünscht angesehen.

6.2.5. Ort des Versionsverwaltungssystems

Es gibt zusätzliche Felder für den Ort des Versionsverwaltungssystems in debian/control.

6.2.5.1. Vcs-Browser

Der Wert dieses Feldes sollte eine https://-URL sein, die auf eine via Webbrowser zu durchsuchende Kopie des Versionsverwaltungssystem-Repositorys verweist, das benutzt wird, um das angegebene Paket zu verwalten, falls verfügbar.

Die Information ist dazu gedacht, dem Endanwender zu helfen, diese Ressource aufzurufen um die letzte am Paket geleistete Arbeit durchstöbern zu können (z.B. wenn nach einem Patch gesucht wird, der einen Fehler behebt, der in der Fehlerdatenbank als pending gekennzeichnet ist).

6.2.5.2. Vcs-*

Der Wert dieses Feldes sollte eine Zeichenkette sein, die den Ort des Versionsverwaltungssystem-Repositorys eindeutig identifiziert, das zur Verwaltung des angegebenen Pakets benutzt wird, falls verfügbar. * identifiziert das Versionsverwaltungssystem. Aktuell werden vom Paketverfolgungssystem die folgenden Typen unterstützt: arch, bzr (Bazaar), cvs, darcs, git, hg (Mercurial), mtn (Monotone) und svn (Subversion).

Die Information ist für Benutzer bestimmt, die im gegebenen Versionsverwaltungssystem sachkundig sind und bereit, die aktuelle Version des Pakets aus den VCS-Quellen zu erstellen. Andere Nutzungen dieser Information könnten das automatische Erstellen der letzten VCS-Version des Pakets umfassen. Dazu sollte der vom Feld angegebene Ort versionsunabhängig sein und auf den Hauptzweig (main branch) zeigen (bei Versionsverwaltungssystemen, die dieses Konzept unterstützen). Außerdem sollte der Endanwender auf den Ort zugreifen können, auf den verwiesen wird. Die Erfüllung dieser Anforderungen könnte einen anonymen Zugriff voraussetzen, statt auf eine Version mit SSH-Zugriff zu verweisen.

Im folgendem Beispiel wird eine Instanz des Felds für ein Git-Repository des vim-Pakets angezeigt. Beachten Sie, dass die URL das https://- Schema (anstelle von ssh://) benutzt. Die Verwendung der Felder Vcs-Browser und Homepage wird ebenfalls gezeigt, wie oben beschrieben.

Source: vim
<snip>
Vcs-Git: https://salsa.debian.org/vim-team/vim.git
Vcs-Browser: https://salsa.debian.org/vim-team/vim
Homepage: https://www.vim.org

Das Verwalten der Paketierung in einem Versionskontrollsystem und das Festlegen eines Vcs-*-Headers ist eine bewährte Vorgehensweise und erleichtert anderen das Einbringen von Änderungen.

Fast alle Pakete in Debian, die ein Versionskontrollsystem verwenden, verwenden Git. Wenn Sie ein neues Paket erstellen, ist die Verwendung von Git eine gute Idee, einfach weil es das System ist, mit dem die Mitwirkenden vertraut sind.

DEP-14 definiert ein allgemein gültiges Layout für Debian Pakete.

6.3. Optimale Vorgehensweisen für debian/changelog

Die folgenden Vorgehensweisen ergänzen die Richtlinien für Änderungsprotokolldateien.

6.3.1. Verfassen nützlicher Änderungsprotokolleinträge

Der Änderungsprotokolleintrag (Changelog) einer Paketüberarbeitung dokumentiert Änderungen der aktuellen Version, und nur diese. Der Schwerpunkt liegt auf der Beschreibung bedeutender und für den Anwender sichtbarer Änderungen, die seit der letzten Version vorgenommen wurden.

Der Fokus liegt darauf, was geändert wurde – wer, wie und wann ist normalerweise nicht so wichtig. Erinnern Sie gleichwohl höflich an die Leute, die merklich Hilfe beim Erstellen des Pakets geleistet haben (die z.B. Patches gesandt haben).

Es ist nicht nötig, belanglose und offensichtliche Änderungen näher auszuführen. Sie können außerdem mehrere Änderungen in einem Eintrag zusammenfassen. Fassen Sie sich andererseits nicht zu kurz, falls Sie eine größere Änderung vorgenommen haben. Stellen Sie insbesondere klar, falls es Änderungen gibt, die das Verhalten des Programms ändern. Benutzen Sie für weitere Erklärungen die Datei README.Debian.

Benutzen Sie geläufiges Englisch, so dass die Mehrheit der Leser es begreifen kann. Vermeiden Sie Abkürzungen, technische Begriffe und Fachsprache, wenn Sie Änderungen erklären, die Fehlerberichte schließen, insbesondere bei Fehlern die von Anwendern eingereicht wurden, die Ihnen als technisch unerfahren aufgefallen sind. Seien Sie höflich, fluchen Sie nicht.

Manchmal ist es wünschenswert, den Änderungsprotokolleinträgen die Namen der Dateien voranstellen, die geändert wurden. Es ist jedoch nicht nötig, explizit jede einzelne geänderte Datei aufzuführen, insbesondere dann nicht, wenn die Änderung klein oder wiederholend war. Sie können Platzhalter verwenden.

Treffen Sie keine Annahmen wenn Sie sich auf Fehler beziehen. Sagen Sie welches Problem vorlag, wie es behoben wurde und hängen Sie die Zeichenkette "closes: #nnnnn" an. Weitere Informationen erhalten Sie unter Wann Fehler durch neue Uploads geschlossen werden.

6.3.2. Auswahl Dringlichkeit des Uploads

Das Release-Team hat angegeben, dass sie erwarten, dass die meisten Uploads nach unstable die Dringlichkeit urgency=medium verwenden. Deshalb sollten Sie urgency=medium benutzen, es sei denn, es gibt spezielle Gründe, dass der Upload schneller oder langsamer nach testing migrieren soll (Siehe auch:ref:testing-unstable). Beispielsweise können Sie urgency=low nehmen, falls die Änderungen seit dem letzten Upload sehr umfangreiche oder disruptive, unerwartete Änderungen enthalten.

Die Verzögerungen betragen derzeit je nach Dringlichkeit (hoch, mittel oder niedrig) 2, 5 oder 10 Tage. Die tatsächlichen Zahlen werden durch die „Britney-Konfiguration <https://release.debian.org/britney/britney.conf>“__ gesteuert, die auch beschleunigte Migrationen umfasst, wenn der Autopkgtest erfolgreich ist.

6.3.3. Häufige Missverständnisse über Änderungsprotokolleinträge

Die Änderungsprotokolleinträge sollten keine allgemeinen Paketierungsthemen dokumentieren (Hey, falls Sie die Foo.conf suchen, die ist in /etc/blah/.), da von Administratoren und Anwendern angenommen wird, dass sie zumindest entfernt damit vertraut sind, wie solche Dinge im Allgemeinen auf Debian-Systemen eingerichtet sind. Erwähnen Sie jedoch, wenn Sie den Ort einer Konfigurationsdatei ändern.

Die einzigen Fehler, die mit einem Änderungsprotokolleintrag geschlossen werden, sollten Fehler sein, die tatsächlich in der gleichen Überarbeitung des Pakets behoben werden. Das Schließen von Fehlern ohne Bezug dazu, ist eine falsche Vorgehensweise. Siehe Wann Fehler durch neue Uploads geschlossen werden.

Die Änderungsprotokolleinträge sollten nicht für zufällige Diskussionen mit Leuten, die Fehler melden (Ich kann keine Schutzverletzungen sehen, wenn ich Foo mit der Option Bar starte. Senden Sie weitere Informationen.), allgemeine Äußerungen über das Leben, das Universum und alles mögliche (Entschuldigung, dass der Upload so lange brauchte, aber ich hatte die Grippe.) oder Hilfeersuchen (Die Fehlerliste für dieses Paket ist riesig, bitte packen Sie mit an) benutzt werden. Solche Dinge werden normalerweise nicht von Ihrer Zielgruppe bemerkt, könnten aber viele Leute stören, die Informationen über tatsächliche Änderungen am Paket lesen möchten. Weitere Informationen über die Benutzung der Fehlerdatenbank finden Sie unter Auf Fehler antworten.

Es ist ein alter Brauch, im ersten regulären Upload des Paketbetreuers das Beheben von Fehlern durch Non-Maintainer-Uploads zu bestätigen. Da Debian nun über eine Versionsverwaltung verfügt, reicht es aus, die NMU-Änderungsprotokolleinträge zu erhalten und diese Tatsache nur in Ihrem eigenen Änderungsprotokolleintrag zu erwähnen.

6.3.4. Häufige Fehler in Änderungsprotokolleinträgen

Die folgenden Beispiele demonstrieren einige häufige Fehler oder Beispiele für schlechten Stil in Änderungsprotokolleinträgen.

* Fixed all outstanding bugs.

Dies teilt den Lesern offensichtlich nichts Nützliches mit.

* Applied patch from Jane Random.

Was war das für ein Patch?

* Late night install target overhaul.

Welche Korrektur wurde ausgeführt? Soll die Erwähnung der späten Nacht daran erinnern, dass man dem Code nicht trauen sollte?

* Fix vsync fw glitch w/ ancient CRTs.

Hier werden zu viele Akronyme benutzt! Was bedeuted "fw", eventuell "firmware"? Und es ist nicht allzu klar, worum es bei dem Fehler tatsächlich ging oder wie er behoben wurde.

* This is not a bug, closes: #nnnnnn.

Erst einmal ist es absolut unnötig, das Paket hochzuladen, um diese Information zu übermitteln. Benutzen Sie stattdessen die Fehlerdatenbank. Zweitens fehlt die Erklärung, warum dieser Bericht kein Fehler ist.

* Has been fixed for ages, but I forgot to close; closes: #54321.

Falls Sie aus irgend einem Grund die Fehlernummer in einem früheren Änderungsprotokolleintrag nicht erwähnt haben, ist das kein Problem. Schließen Sie den Fehler einfach im BTS. Es ist nicht nötig, die Änderungsprotokolldatei anzufassen, vorausgesetzt, die Beschreibung der Fehlerbehebung ist bereits darin enthalten (dies gilt auch für Korrekturen durch die Originalautoren/-Betreuer. Sie müssen keine Fehler verfolgen, die diese bereits vor Jahren in Ihrem Änderungsprotokoll behoben haben).

* Closes: #12345, #12346, #15432

Wo ist die Beschreibung? Falls Ihnen keine aussagekräftige Nachricht einfällt, beginnen Sie damit, die Titel der verschiedenen Fehler einzufügen.

6.3.5. Änderungsprotokolle mit NEWS.Debian-Dateien ergänzen

Wichtige Nachrichten über Änderungen in einem Paket können auch in die NEWS.Debian-Dateien geschrieben werden. Die Nachrichten werden durch Werkzeuge wie apt-listchanges vor dem ganzen Rest des Änderungsprotokolls angezeigt. Dies ist das bevorzugte Mittel, dem Anwender bedeutende Änderungen in einem Paket mitzuteilen. Es ist besser, als debconf-Notizen zu benutzen, da es weniger stört und der Anwender nach der Installation zurückgehen und in der NEWS.Debian-Datei nachschlagen kann. Es ist auch besser, als die Hauptänderungen in README.Debian aufzuführen, da der Anwender solche Notizen leicht übersehen kann.

Das Dateiformat entspricht dem des Änderungsprotokolls, die Sternchen werden allerdings weggelassen und jedes Nachrichtenelement wird, wenn nötig, mit einem vollständigen Satz beschrieben, statt der kurz gefassten Zusammenfassungen, die in ein Änderungsprotokoll einfließen. Sie sind gut beraten, Ihre Datei durch dpkg-parsechangelog laufen zu lassen, um die Formatierung zu prüfen, da sie nicht automatisch während des Builds getestet wird, so wie dies beim Änderungsprotokoll geschieht. Hier nun ein Beispiel einer echten NEWS.Debian-Datei:

cron (3.0pl1-74) unstable; urgency=low

    The checksecurity script is no longer included with the cron package:
    it now has its own package, checksecurity. If you liked the
    functionality provided with that script, please install the new
    package.

 -- Steve Greenland <stevegr@debian.org>  Sat,  6 Sep 2003 17:15:03 -0500

Die Datei NEWS.Debian wird als /usr/share/doc/Paket/NEWS.Debian.gz installiert. Sie ist komprimiert und hat immer diesen Namen, auch in nativen Debian-Paketen. Falls Sie debhelper benutzen, wird dh_installchangelogs die debian/NEWS-Dateien für Sie installieren.

Anders als Änderungsprotokolldateien müssen Sie die debian/NEWS-Dateien nicht bei jeder Veröffentlichung aktualisieren. Aktualisieren Sie diese nur, wenn Sie etwas besonders berichtenswertes haben, worüber der Anwender Bescheid wissen sollte. Falls Sie überhaupt keine Nachrichten haben, ist es nicht nötig, Ihrem Paket eine debian/NEWS-Datei mitzugeben. Keine Nachricht ist eine gute Nachricht!

6.4. Optimale Vorgehensweisen rund um Sicherheit

Eine Reihe von Vorschlägen und Links zu anderen Referenzdokumenten rund um Sicherheitsaspekte beim Paketieren finden Sie im Kapitel Developer's Best Practices for OS Security.

6.5. Optimale Vorgehensweisen für Betreuerskripte

Zu den Betreuerskripten gehören die Dateien debian/postinst, debian/preinst, debian/prerm und debian/postrm. Diese Skripte kümmern sich um die Paketeinrichtung bei jeder Installation oder Deinstallation des Pakets, bei dem es nicht ausreicht, nur die Dateien und Verzeichnisse zu erstellen oder zu entfernen. Die folgenden Anweisungen ergänzen die Debian Policy.

Betreuerskripte müssen idempotent sein. Das bedeutet, dass Sie sicherstellen müssen, dass nichts Schlimmes passiert, wenn das Skript zweimal aufgerufen wird, während es normalerweise nur einmal aufgerufen würde.

Standardein- und -ausgabe könnten zu Protokollierungszwecken umgeleitet werden (z.B. in Pipes), verlassen Sie sich daher nicht darauf, dass dies auf einem Terminal ausgegeben werden.

Jegliche Bedienerführung oder interaktive Konfiguration sollte so gering wie möglich gehalten werden. Wenn es nötig ist, sollten Sie das Paket debconf für die Schnittstelle benutzen. Denken Sie daran, dass diese Bedienerführung nur in der configure-Stufe des postinst-Skripts stattfinden kann.

Halten Sie die Betreuerskripte so einfach wie möglich. Es wird empfohlen, nur reine POSIX-Shell-Skripte zu benutzen. Falls Sie irgendwelche Bash-Funktionen benötigen, vergessen Sie nicht, dass das Betreuerskript eine Shebang-Zeile haben muss. POSIX-Shell oder Bash werden für Perl bevorzugt, da sie debhelper ermöglichen, den Skripten einfach Teile hinzuzufügen.

Falls Sie Ihre Betreuerskripte ändern, stellen Sie sicher, dass Sie das Entfernen des Pakets, die mehrmalige Installation und das vollständige Entfernen testen. Vergewissern Sie sich, dass nach dem vollständigen Entfernen des Pakets alles komplett gelöscht ist, sprich es muss jede Datei entfernt sein, die direkt oder indirekt in irgendeinem Betreuerskript erstellt wurde.

Falls Sie prüfen möchten, ob ein Befehl existiert, sollten Sie z.B. so etwas benutzen

if command -v install-docs > /dev/null; then ...

Sie können diese Funktion benutzen, um $PATH nach einem Befehlsnamen zu durchsuchen, der als Argument übergeben wird. Sie gibt "true" (null) zurück, falls der Befehl gefunden wurde und "false" falls nicht. Dies ist wirklich die am ehesten portierbare Möglichkeit, da command -v ein Shell-Builtin für viele Shells ist und im POSIX-Standard definiert ist.

Das Benutzen von which ist eine akzeptable Alternative da es im erforderlichen Paket debianutils enthalten ist.

6.6. Konfigurationsverwaltung mit debconf

Debconf ist ein Konfigurationsverwaltungssystem, das von allerlei Paketierungsskripten (hauptsächlich postinst) benutzt werden kann, um Rückmeldungen von Anwendern betreffend der Paketkonfiguration abzufragen. Direkte Benutzer-Interaktion muss nun zugunsten der Interaktion mit debconf vermieden werden, damit in Zukunft nicht interaktive Installationen möglich sind.

Debconf ist ein großartiges Werkzeug, aber es wird oft mangelhaft benutzt. Viele alltägliche Fehler sind auf der Handbuchseite debconf-devel 7 aufgeführt. Sie sollten sie lesen, falls Sie sich entscheiden debconf zu benutzen. Außerdem werden hier ein paar optimale Vorgehensweisen vorgestellt.

Diese Leitlinien enthalten einige Empfehlungen für Schreibstil und Typografie, allgemeine Betrachtungen über die Benutzung von debconf sowie spezifischere Empfehlungen für einige Teile der Distribution (das Installationssystem beispielsweise).

6.6.1. Missbrauchen Sie debconf nicht

Seit debconf in Debian erschien, wurde es öfter missbraucht und viel von der Kritik, die bei der Debian-Distribution einging, rührte vom debconf-Missbrauch her und bemängelte die Notwendigkeit, ein großes Fragenbündel beantworten zu müssen, bevor eine Kleinigkeit installiert war.

Lassen Sie Hinweise zur Benutzung der Software dort wozu sie gehören: In den Dateien NEWS.Debian oder README.Debian. Benutzen Sie debconf-Meldungen nur für wichtige Anmerkungen die direkt die Benutzbarkeit des Pakets betreffen. Bedenken Sie, dass diese die Installation immer blockieren bis diese bestätigt wurden, oder Sie belästigen den Anwender per E-Mail.

Wählen Sie die Prioritäten der Fragen in Betreuerskripten sorgfältig. Einzelheiten über Prioritäten finden Sie unter debconf-devel 7. Die meisten Fragen sollten mittlere oder niedrige Prioritäten nutzen.

6.6.2. Allgemeine Empfehlungen für Autoren und Übersetzer

6.6.2.1. Schreiben Sie korrektes Englisch

Die meisten Debian-Paketbetreuer haben nicht Englisch als Muttersprache. Daher ist es für sie nicht einfach, korrekt formulierte Vorlagen zu verfassen.

Bitte benutzen (und missbrauchen) Sie die Mailingliste debian-l10n-english@lists.debian.org. Lassen Sie Ihre Vorlagen dort Korrekturlesen.

Schlecht geschriebene Vorlagen werfen ein armseliges Bild auf Ihr Paket, Ihre Arbeit ... oder sogar auf Debian selbst.

Vermeiden Sie soweit möglich technische Fachsprache. Auch wenn sich einige Begriffe für Sie vertraut anhören, könnten sie für andere unverständlich sein. Falls sie sich nicht vermeiden lassen, versuchen Sie diese zu erklären (benutzen Sie die erweiterte Beschreibung). Versuchen Sie dabei, zwischen Aussagekraft und Einfachheit abzuwägen.

6.6.2.2. Seien Sie freundlich zu Übersetzern

Debconf-Vorlagen können übersetzt werden. Debconf bietet zusammen mit seinem Schwesterpaket po-debconf ein einfaches Werkzeug, um Vorlagen durch Übersetzer-Teams oder sogar einzelne Personen übersetzen zu lassen.

Bitte benutzen Sie Gettext-basierte Vorlagen. Installieren Sie po-debconf auf Ihrem Entwicklungssystem und lesen Sie dessen Dokumentation (man po-debconf ist ein guter Anfang).

Vermeiden Sie es, Vorlagen häufig zu ändern. Das Ändern von Vorlagen führt zu Mehrarbeit für Übersetzer, deren Übersetzungen unvollständig werden. Eine unvollständige Übersetzung ist eine Zeichenkette, bei der sich seit dem Übersetzen das Original geändert hat und das daher eine Aktualisierung durch den Übersetzer benötigt. Wenn die Änderungen klein genug sind, wird die Originalübersetzung in den PO-Dateien beibehalten, jedoch mit fuzzy gekennzeichnet.

Falls Sie planen, Änderungen an Ihren Originalvorlagen vorzunehmen, benutzen Sie bitte das Benachrichtigungssystem namens podebconf-report-po, das vom Paket po-debconf bereitgestellt wird, um die Übersetzer zu kontaktieren. Die meisten aktiven Übersetzer sind sehr zugänglich, und deren Arbeit zusammen mit Ihren geänderten Vorlagen einzubeziehen, wird Sie vor zusätzlichen Uploads bewahren. Falls Sie Gettext-basierte Vorlagen verwenden, werden die Namen und E-Mail-Adressen der Übersetzer in den Kopfzeilen der PO-Dateien erwähnt und von podebconf-report-po benutzt.

Ein empfohlene Art, das Hilfswerkzeug zu benutzen ist:

cd debian/po && podebconf-report-po --call --languageteam --withtranslators --deadline="+10 days"

Dieser Befehl wird zuerst die PO- und POT-Dateien in debian/po mit den in debian/po/POTFILES.in aufgeführten Vorlagendateien synchronisieren. Dann wird er einen Aufruf für neue Übersetzungen an die Mailingliste debian-i18n@lists.debian.org senden. Am Schluss wird er außerdem einen Aufruf für neue Übersetzungen an das Sprach-Team (im Feld Language-Team jeder PO-Datei erwähnt), sowie den letzten Übersetzer (aus Last-Translator) senden.

Es wird immer gewürdigt, wenn Sie den Übersetzern einen Abgabetermin nennen, so dass diese ihre Arbeit organisieren können. Bitte denken Sie daran, dass einige Übersetzer-Teams einen formalisierten Übersetzungs-/Korrekturprozess haben und eine Zeitspanne, die kürzer als zehn Tage ist, als unangemessen angesehen wird. Eine kürzere Frist übt zuviel Druck auf die Übersetzer-Teams aus und sollte nur für sehr kleine Änderungen gewählt werden.

Im Zweifelsfall können Sie auch das Übersetzer-Team für eine bestimmte Sprache (debian-l10n-xxxxx@lists.debian.org) oder die Mailingliste debian-i18n@lists.debian.org kontaktieren.

6.6.2.3. Entfernen Sie die fuzzy-Markierungen in vollständigen Übersetzungen, wenn Sie Tipp- und Rechtschreibfehler korrigieren

Wenn der Text einer Debconf-Vorlage korrigiert wurde und Sie sicher sind, dass die Änderung keine Übersetzungen beeinflusst, seien Sie so nett zu den Übersetzern, die fuzzy-Markierungen aus deren Übersetzungen zu entfernen.

Falls Sie dies nicht tun, wird die ganze Vorlage nicht übersetzt sein, bis Ihnen ein Übersetzer eine Aktualisierung zusendet.

Um die fuzzy-Markierungen aus Übersetzungen zu entfernen, können Sie msguntypot benutzen (Teil des Pakets po4a).

1. Erzeugen Sie die POT- und PO-Dateien neu.

   debconf-updatepo
   

2. Erstellen Sie eine Kopie der POT-Datei.

   cp templates.pot templates.pot.orig
   

3. Erstellen Sie eine Kopie aller PO-Dateien.

   mkdir po_fridge; cp *.po po_fridge
   

4. Ändern Sie die Debconf-Vorlagedateien, um den Tippfehler zu korrigieren.

5. Erzeugen Sie die POT- und PO-Dateien (wieder) neu.

   debconf-updatepo
   

   An dieser Stelle markiert die Korrektur des Tippfehlers alle Übersetzungen mit "fuzzy" und diese unglückliche Änderung ist die einzige zwischen den PO-Dateien Ihres Hauptverzeichnisses und denen aus fridge. Hier nun eine Erklärung, wie das gelöst wird.

6. Verwerfen Sie die mit "fuzzy" markierte Übersetzung und stellen Sie die aus fridge wieder her.

   cp po_fridge/*.po .
   

7. Führen Sie manuell die PO-Dateien mit der neuen POT-Datei zusammen, unter Berücksichtigung/Vermeidung des nutzlosen "fuzzy".

   msguntypot -o templates.pot.orig -n templates.pot *.po
   

8. Räumen Sie auf.

   rm -rf templates.pot.orig po_fridge
   

6.6.2.4. Treffen Sie keine Annahmen über Schnittstellen

Vorlagentexte sollten keinen Bezug zu Steuerelementen herstellen, die zu irgendwelchen Debconf-Schnittstellen gehören. Sätze wie Wenn Sie mit Ja antworten... haben keinen Sinn für Benutzer grafischer Oberflächen, weil dort bei logischen Fragen Kontrollkästchen angehakt werden.

Zeichenkettenvorlagen sollten außerdem vermeiden, Vorgabewerte in ihrer Beschreibung zu erwähnen. Erstens sind diese zusätzlich zu den Werten, die der Anwender sieht, vorhanden. Außerdem könnten sich diese Werte von der Auswahl des Paketbetreuers unterscheiden (zum Beispiel, wenn die Debconf-Datenbank voreingestellt ist).

Versuchen Sie, allgemein ausgedrückt, Bezug auf Benutzeraktionen zu vermeiden. Geben Sie nur Tatsachen wieder.

6.6.2.5. Reden Sie nicht in der ersten Person

Sie sollten vermeiden, in der ersten Person zu reden (Ich werde das tun... oder Wir empfehlen...). Der Rechner ist keine Person und die Debconf-Vorlagen sprechen nicht stellvertretend für Debian-Entwickler. Sie sollten neutrale Formulierungen benutzen. Diejenigen unter Ihnen, die bereits wissenschaftliche Publikationen verfasst haben, können ihre Vorlagen so schreiben, als würden Sie wissenschaftliche Papiere verfassen. Versuchen Sie jedoch, wenn möglich eine aktive Anrede zu verwenden, wie Aktivieren Sie dies, wenn ... anstelle von Dies kann aktiviert werden, wenn....

6.6.2.6. Formulieren Sie geschlechtsneutral

Um unser Bekenntnis zu unserem Diversity Statement zu zeigen, verwenden Sie bitte in Ihren Texten geschlechtergerechte Formulierungen, indem Sie Pronomen wie "Er" oder "Sie" vermeiden, wenn Sie auf eine Aufgabenrolle (wie zum Beispiel Betreuer) Bezug nehmen.

6.6.3. Definition von Vorlagenfeldern

Dieser Teil stellt einige Informationen bereit, die überwiegend von der Handbuchseite debconf-devel 7 übernommen wurden.

6.6.3.1. Typen

6.6.3.1.1. string

Resultiert in einem Eingabefeld freier Form, in das der Benutzer jegliche Zeichenkette eingeben kann.

6.6.3.1.2. password

Gibt dem Benutzer eine Eingabeaufforderung für ein Passwort aus. Benutzen Sie dies mit Vorsicht. Vergegenwärtigen Sie sich, dass das Passwort das der Benutzer eingibt in die Debconf-Datenbank geschrieben wird. Sie sollten diesen Wert möglicherweise aus der Datenbank löschen, sobald dies möglich ist.

6.6.3.1.3. boolean

Eine Auswahl "wahr/falsch". Denken Sie daran: true/false, nicht yes/no ...

6.6.3.1.4. select

Eine Auswahl aus mehreren Werten. Die Auswahlmöglichkeiten müssen in einem "Choices" benannten Feld angegeben werden. Trennen Sie die möglichen Werte mit Komma und Leerzeichen, wie hier: Choices: yes, no, maybe.

Falls Auswahlmöglichkeiten übersetzbare Zeichenketten sind, kann das Feld durch Benutzung von __Choices als übersetzbar gekennzeichnet werden. Der doppelte Unterstrich wird jede Auswahl in eine separate Zeichenkette heraus trennen.

Das System po-debconf bietet außerdem interessante Möglichkeiten, um nur einige Auswahlmöglichkeiten als übersetzbar zu kennzeichnen. Ein Beispiel:

Template: foo/bar
Type: Select
#flag:translate:3
__Choices: PAL, SECAM, Other
_Description: TV standard:
 Please choose the TV standard used in your country.

In diesem Beispiel ist nur die Zeichenkette "Other" übersetzbar, während das andere Abkürzungen sind, die nicht übersetzt werden sollten. Obiges ermöglicht, dass nur "Other" in die POT- und PO-Dateien eingefügt wird.

Das Schaltersystem der Debconf-Vorlagen bietet viele solcher Möglichkeiten. Die Handbuchseite po-debconf 7 führt all diese Möglichkeiten auf.

6.6.3.1.5. multiselect

Wie der Datentyp "select", außer dass der Benutzer eine beliebige Anzahl von Elementen aus der Auswahlliste auswählen kann (oder gar keins).

6.6.3.1.6. note

Statt per se als Frage stellt dieser Datentyp einen Hinweis dar, der dem Benutzer angezeigt werden kann. Er sollte nur für wichtige Anmerkungen benutzt werden, die der Benutzer wirklich sehen sollte, weil debconf großen Aufwand betreibt, um sicherzustellen, dass der Benutzer sie wahrnimmt; die Installation wird gestoppt, bis der Benutzer eine Taste drückt, in manchen Fällen bekommt er sogar eine Benachrichtigung per E-Mail.

6.6.3.1.7. text

Dieser Typ wird nun als veraltet angesehen: Benutzen Sie ihn nicht.

6.6.3.1.8. error

Dieser Typ wurde für Fehlermeldungen entworfen. Er ist dem Typ "note" am ähnlichsten. Oberflächen könnten ihn unterschiedlich anzeigen (die Oberfläche von Cdebconf zeichnet beispielsweise einen roten statt des üblichen blauen Bildschirms).

Es wird empfohlen, diesen Typ für jegliche Nachricht zu verwenden, die die Aufmerksamkeit des Anwenders für irgendeine Art von Korrektur auf sich ziehen muss.

6.6.3.2. Description: Kurze und erweiterte Beschreibung

Vorlagenbeschreibungen haben zwei Teile: kurz und erweitert. Die Kurzbeschreibung steht in der Zeile "Description:" der Vorlage.

Die Kurzbeschreibung sollte knapp gehalten werden (ungefähr 50 Zeichen), so dass sie in den meisten debconf-Schnittstellen untergebracht werden kann. Es hilft obendrein Übersetzern, wenn sie kurz gehalten wird, da Übersetzungen normalerweise dazu neigen, länger als das Original zu sein.

Die Kurzbeschreibung sollte für sich allein stehen können. Einige Schnittstellen zeigen die ausführliche Beschreibung standardmäßig nicht an, oder nur, wenn der Benutzer explizit danach fragt, oder eventuell wird sie gar nicht angezeigt. Vermeiden Sie so was wie "Was möchten Sie tun?"

Die Kurzbeschreibung muss nicht notwendigerweise aus einem vollständigen Satz bestehen. Dies ist Teil der Forderung nach kurzen, brauchbaren Empfehlungen.

Die erweiterte Beschreibung sollte die Kurzbeschreibung nicht Wort für Wort wiederholen. Falls Ihnen keine ausführliche Beschreibung einfällt, denken Sie zuerst etwas darüber nach. Schreiben Sie an debian-devel. Bitten Sie um Hilfe. Nehmen Sie Schreibunterricht! Diese erweiterte Beschreibung ist wichtig. Falls Sie nach allem noch immer nicht damit zurecht kommen, lassen Sie sie leer.

Die erweiterte Beschreibung sollte in ganzen Sätzen verfasst sein. Absätze sollten kurz gehalten werden, um die Leserlichkeit zu verbessern. Vermischen Sie nicht zwei Ideen in einem Absatz, sondern benutzen Sie lieber einen anderen Absatz.

Seien Sie nicht zu gesprächig. Benutzer tendieren dazu, zu ausführliche Bildschirminhalte zu ignorieren. 20 Zeilen sind erfahrungsgemäß die Grenze, die Sie nicht überschreiten sollten, da dies bedeutet, dass Anwender klassische Dialogfenster nicht scrollen müssen und viele Leute tun das einfach nicht.

Die erweiterte Beschreibung sollte keine Frage enthalten.

Um etwas über besondere Regeln zu erfahren, die vom Vorlagentyp (string, boolean etc.) abhängen, lesen Sie das Folgende.

6.6.3.3. Choices

Dieses Feld sollte für "select"- und "multiselect"-Typen verwandt werden. Es enthält die Auswahlmöglichkeiten, die dem Benutzer angezeigt werden. Die Auswahlmöglichkeiten sollten durch Komma getrennt werden.

6.6.3.4. Default

Dieses Feld ist optional. Es enthält die vorausgewählte Antwort für die "string"-, "select"- und "multiselect"-Vorlagen. Für "multiselect"-Vorlagen könnte es eine durch Komma getrennte Auswahlliste enthalten.

6.6.4. Gestaltungsrichtlinie für Vorlagenfelder

6.6.4.1. Feld "Type"

Keine besondere Angabe außer: Benutzen Sie den geeigneten Typ bezogen auf den vorhergehenden Abschnitt.

6.6.4.2. Feld "Description"

Es folgen spezifische Anweisungen für ordnungsgemäßes Verfassen der Beschreibung (kurz und erweitert), abhängig vom Vorlagentyp.

6.6.4.2.1. "string"-/"password"-Vorlagen

• Die Kurzbeschreibung ist eine Abfrage und kein Titel. Vermeiden Sie den Fragestil (IP-Adresse?) und geben Sie offenen Abfragen (IP-Adresse:) den Vorzug. Es wird empfohlen, Doppelpunkte zu benutzen.

• Die erweiterte Beschreibung ist eine Ergänzung der Kurzbeschreibung. Im erweiterten Teil erklären Sie, was gefragt ist, anstatt die gleiche Frage in längerer Formulierung wieder zu stellen. Benutzen Sie ganze Sätze. Von knappem Schreibstil wird strikt abgeraten.

6.6.4.2.2. "boolean"-Vorlagen

• Die Kurzbeschreibung sollte als Frage formuliert und kurz gehalten werden, und generell mit einem Fragezeichen enden. Kompakter Schreibstil ist erlaubt und sogar gewollt, falls die Frage eher lang ist. (Denken Sie daran, dass Übersetzungen oft länger als die Originalversionen sind.)

• Nochmals: Bitte vermeiden Sie, sich auf Schnittstellen-spezifische Dinge zu beziehen. Ein häufiger Fehler bei solchen Vorlagen ist, auf Ja-Typ-Konstruktionen zu antworten.

6.6.4.2.3. "select"/"multiselect"

• Die Kurzbeschreibung ist eine Abfrage und kein Titel. Benutzen Sie keine nutzlosen "Bitte wählen Sie..."-Konstruktionen. Anwender sind klug genug, um herauszufinden, dass sie etwas auswählen sollen ... :)

• Die erweiterte Beschreibung wird die Kurzbeschreibung vervollständigen. Sie könnte sich auf die verfügbaren Auswahlmöglichkeiten beziehen. Sie könnte zudem erwähnen, dass der Anwender unter mehr als einer verfügbaren Auswahlmöglichkeit wählen kann, falls es sich um eine "multiselect"-Vorlage handelt.

6.6.4.2.4. "notes"

• Die Kurzbeschreibung sollte als Titel betrachtet werden.

• Die erweiterte Beschreibung ist das, was als detaillierte Erklärung der Notiz angezeigt wird. Sätze, kein knapper Schreibstil.

• Missbrauchen Sie debconf nicht. Anmerkungen sind die häufigste Art, auf die debconf missbraucht wird. Wie steht doch in der Handbuchseite von "debconf-devel" geschrieben: Es ist am Besten, dies nur für Warnungen über sehr ernsthafte Probleme zu benutzen. Die Dateien NEWS.Debian oder README.Debian sind für viele Notizen der passende Ort. Wenn Sie dies lesen, und darüber nachdenken, Ihre "notes" zu Einträgen in NEWS.Debian oder README.Debian umzuwandeln, bewahren Sie bitte dennoch Ihre existierenden Übersetzungen für die Zukunft auf.

6.6.4.3. Das Feld "Choices"

Falls sich "Choices" zu oft ändert, sollten Sie in Betracht ziehen, zum __Choices-Trick zu greifen. Dies wird jede einzelne Auswahl in eine einzelne Zeichenkette aufteilen, was Übersetzern beträchtlich bei ihrer Arbeit helfen wird.

6.6.4.4. Das Feld "Default"

Wenn der Standardwert für eine ausgewählte Vorlage wahrscheinlich von der Benutzersprache abhängt (z. B. wenn es sich bei der Auswahl um eine Sprachauswahl handelt), verwenden Sie bitte den in po-debconf 7 dokumentierten Trick _Default.

Dieses Spezialfeld ermöglicht Übersetzern, die am Besten zu ihrer Sprache passende Auswahl zu wählen. Der vom Übersetzer gewählte Standardeintrag wird verwendet, wenn deren Sprache benutzt wird, während Ihre eigene "Default"-Auswahl bei Englisch benutzt wird.

Verwenden Sie kein leeres Standardfeld. Wenn Sie keine Standardwerte verwenden möchten, verwenden Sie kein Feld "Default".

Falls Sie po-debconf benutzen (und das sollten Sie, lesen Sie Seien Sie freundlich zu Übersetzern), erwägen Sie, dieses Feld übersetzbar zu machen, wenn es nach Ihrer Meinung übersetzt werden könnte.

Ein Beispiel aus den Vorlagen des Pakets Geneweb:

Template: geneweb/lang
Type: select
__Choices: Afrikaans (af), Bulgarian (bg), Catalan (ca), Chinese (zh), Czech (cs), Danish (da), Dutch (nl), English (en), Esperanto (eo), Estonian (et), Finnish (fi), French (fr), German (de), Hebrew (he), Icelandic (is), Italian (it), Latvian (lv), Norwegian (no), Polish (pl), Portuguese (pt), Romanian (ro), Russian (ru), Spanish (es), Swedish (sv)
# This is the default choice. Translators may put their own language here
# instead of the default.
# WARNING : you MUST use the ENGLISH NAME of your language
# For instance, the French translator will need to put French (fr) here.
_Default: English[ translators, please see comment in PO files]
_Description: Geneweb default language:

Beachten Sie, dass die Benutzung von Klammern Kommentare in debconf-Feldern erlaubt. Beachten Sie außerdem, dass die Kommentare in den Dateien zu sehen sein werden, mit denen Übersetzer arbeiten.

Die Kommentare werden benötigt, da der _Default-Trick etwas verwirrend ist: Die Übersetzer können ihre eigene Wahl treffen.

6.7. Internationalisierung

Dieser Abschnitt enthält generelle Informationen, um Übersetzern die Arbeit zu erleichtern. Weitere Informationen für Übersetzer und Entwickler zum Thema Internationalisierung sind in der Dokumentation Internationalisierung und Lokalisierung verfügbar.

6.7.1. Handhabung von Debconf-Übersetzungen

Wie Portierer haben auch Übersetzer eine schwierige Aufgabe. Sie arbeiten an vielen Paketen und müssen mit vielen verschiedenen Paketbetreuern zusammenarbeiten, deren Muttersprache meist nicht Englisch ist. Sie sollten ihnen daher besondere Geduld entgegenbringen.

Das Ziel von debconf war die Vereinfachung der Paketkonfiguration für Betreuer und Anwender. Ursprünglich wurde die Übersetzung von Debconf-Vorlagen mit debconf-mergetemplate gehandhabt. Nun wird diese Technik jedoch missbilligt. Die Internationalisierung von debconf ist am besten mit dem Paket po-debconf zu erreichen. Diese Methode ist sowohl für Betreuer als auch für Übersetzer einfacher. Es werden Umwandlungsskripte bereitgestellt.

Wenn po-debconf benutzt wird, werden die Übersetzungen in .po-Dateien gespeichert (mit gettext-Übersetzungstechniken erstellt). Spezielle Vorlagendateien enthalten die Originalnachrichten und markieren, welche Felder übersetzbar sind. Wenn Sie den Wert eines übersetzbaren Feldes durch Aufruf von debconf-updatepo ändern, wird die Übersetzung für Übersetzer als aufmerksamkeitsbedürfend gekennzeichnet. Dann, während des Paketbaus, wird das Programm dh_installdebconf wie von Zauberhand dafür sorgen, dass alle Vorlagen zusammen mit den aktuellen Übersetzungen in die Binärpakete einfließen. Weitere Einzelheiten können Sie der Handbuchseite po-debconf 7 entnehmen.

6.7.2. Internationalisierte Dokumentation

Internationalisierte Dokumentation für Anwender ist wichtig, bereitet aber viel Mühe. Es gibt keine Möglichkeit, all diese Arbeit zu vermeiden, aber Sie können den Übersetzern einige Dinge erleichtern.

Falls Sie Dokumentationen in irgendwelchem Umfang betreuen, ist es für Übersetzer einfacher, wenn Sie Zugriff auf das Versionsverwaltungssystem haben. Dadurch können Übersetzer die Unterschiede zwischen zwei Versionen der Dokumentation anschauen, so dass sie beispielsweise sehen können, was neu übersetzt werden muss. Es wird empfohlen, dass die übersetzte Dokumentation eine Notiz darüber bereithält, auf welcher Revision des Quellcodes die Übersetzung basiert. Ein interessantes System wird von doc-check aus dem debian-installer-Paket bereitgestellt, das eine Übersicht über den Übersetzungsstatus für eine angegebene Sprache anzeigt. Dazu werden strukturierte Kommentare für die aktuelle Revision der zu übersetzenden Datei und für eine übersetzte Datei die Revision des Originals auf der die Übersetzung basiert, angezeigt. Möglicherweise möchten Sie dies anpassen und in Ihrem VCS-Bereich bereitstellen.

Falls Sie XML- oder SGML-Dokumentationen betreuen, wird dazu empfohlen, dass Sie jegliche sprach-unabhängigen Informationen isolieren und diese als Entity in einer eigenen Datei definieren, die in allen verschiedenen Übersetzungen enthalten ist. Dies macht es beispielsweise viel einfacher, URLs über mehrere Dateien hinweg aktuell zu halten.

Einige Werkzeuge (z.B. po4a, poxml oder translate-toolkit) sind darauf spezialisiert, übersetzbares Material aus verschiedenen Formaten zu extrahieren. Sie erstellen PO-Dateien, ein für Übersetzer übliches Format, das eine Übersicht darüber gibt, was übersetzt werden muss, wenn das übersetzte Dokument aktualisiert wurde.

6.8. Häufig vorkommende Paketierungssituationen

6.8.1. Pakete benutzen autoconf/automake

Die Dateien config.sub und config.guess von autoconf aktuell zu halten ist für Portierer kritisch, insbesondere auf eher unbeständigen Architekturen. Einige sehr gute Paketierungsvorgehensweisen für jegliche Pakete, die autoconf und/oder automake benutzen, wurden in /usr/share/doc/autotools-dev/README.Debian.gz aus dem Paket autotools-dev zusammengefasst. Es wird eindringlich geraten, diese README-Datei und die folgenden Empfehlungen zu lesen.

6.8.2. Bibliotheken

Das Paketieren von Bibliotheken gestaltet sich fast immer schwierig und dies aus unterschiedlichen Gründen. Die Richtlinien verhängen mehrere Beschränkungen, um ihre Pflege zu erleichtern und sicherzustellen, dass Upgrades so einfach wie möglich sind, wenn eine neue Originalversion herauskommt. Eine kaputte Bibliothek kann dazu führen, dass Dutzende davon abhängige Pakete beschädigt werden.

Gute Vorgehensweisen für das Paketieren von Bibliotheken wurden in der Anleitung zum Paketieren von Bibliotheken zusammengefasst.

6.8.3. Dokumentation

Achten Sie darauf, dass Sie den Richtlinien für Dokumentation folgen.

Falls Ihr Paket Dokumentation enthält, die aus XML oder SGML erstellt wurde, wird empfohlen in den Binärpaket(en) nicht die XML- oder SGML-Quellen mitzuliefern. Falls Anwender den Quellcode der Dokumentation möchten, sollten sie das Quellpaket herunterladen.

Die Richtlinie gibt an, dass die Dokumentation im HTML-Format weitergegeben werden sollte. Außerdem wird empfohlen, die Dokumentation im PDF-Format und als Klartext mitzuliefern, falls geeignet und falls die Ausgabe in einer vernünftigen Qualität möglich ist. Es ist allgemein jedoch nicht angemessen, Klartextversionen von Dokumentationen mitzuliefern, deren Quellformat HTML ist.

Bedeutende mitgelieferte Handbücher sollten sich selbst bei der Installation mit doc-base registrieren. Weitere Einzelheiten erhalten Sie in der Dokumentation des Pakets doc-base.

Die Debian-Richtlinien (Abschnitt 12.1) schreiben vor, dass Handbuchseiten jedem Programm, jedem Hilfswerkzeug und jeder Funktion beiliegen sollten und für andere Objekte, wie Konfigurationsdateien, wird dies nahegelegt. Falls die von Ihnen paketierte Arbeit nicht über eine solche Handbuchseite verfügt, dann überlegen Sie sich, eine zu schreiben, die Ihrem Paket beigefügt und an die Originalautoren gesandt wird.

Die Handbuchseiten müssen nicht direkt im Troff-Format geschrieben werden. Beliebte Quellformate sind Docbook, POD und reST, die mit xsltproc, pod2man beziehungsweise rst2man umgewandelt werden können. In geringerem Maße kann außerdem das Programm help2man benutzt werden, um die Handbuchsseite rudimentär zu erstellen.

6.8.4. Besondere Pakettypen

Mehrere besondere Typen von Paketen haben spezielle Unter-Richtlinien und zugehörige Paketierungsregeln und Vorgehensweisen:

• Perl zugehörige Pakete haben eine Perl-Richtlinie. Einige Beispiele für Pakete, die dieser Richtlinie folgen, sind libdbd-pg-perl (binäres Perl-Modul) oder libmldbm-perl (architekturunabhängiges Perl-Modul).

• Python zugehörige Pakete haben ihre Python-Richtlinie. Siehe /usr/share/doc/python/python-policy.txt.gz im Paket python.

• Emacs zugehörige Pakete haben die Emacs-Richtlinie.

• Java zugehörige Pakete haben ihre Java-Richtlinie.

• OCaml zugehörige Pakete haben ihre eigene Richtlinie, die Sie unter /usr/share/doc/ocaml/ocaml_packaging_policy.gz im Paket ocaml finden können. Ein gutes Beispiel ist das Quellpaket camlzip.

• Pakete, die XML- oder SGML-DTDs bereitstellen, sollten konform zu den Empfehlungen im Paket sgml-base-doc sein.

• Lisp-Pakete sollten sich selbst mit common-lisp-controller registrieren. Siehe dazu /usr/share/doc/common-lisp-controller/README.packaging.

• Rust-Paketierung wird im Debian Rust Team Book beschrieben.

6.8.5. Architekturunabhängige Daten

Es ist unüblich größere Mengen an architekturunabhängiger Daten gemeinsam mit einem Programm zu paketieren. Als Beispiel hierzu seien Audiodateien, eine Symbolsammlung, Hintergrundmuster oder grafische Dateien genannt. Falls die Größe dieser Daten jedoch vernachlässigbar im Vergleich zum Rest des Pakets ist, ist es wahrscheinlich am besten, alles innerhalb eines einzelnen Paket zu paketieren.

Ist die Größe allerdings beachtlich, denken Sie darüber nach, sie in ein separates architekturunabhängiges Paket (_all.deb) auszulagern. Indem Sie dies tun, vermeiden Sie die im Prinzip unötige Vervielfältigung der gleichen Daten in zehn oder mehr .debs, eines pro Architektur! Obwohl dies einigen zusätzlichen Overhead zu den Packages-Dateien verursacht, spart es viel Plattenplatz auf den Debian-Spiegelservern. Das Heraus trennen architekturunabhängiger Daten vermindert auch die Ausführungszeit von lintian (siehe Lint-Werkzeuge für Pakete), wenn es für das ganze Debian-Archiv ausgeführt wird.

6.8.6. Eine bestimmte Locale wird während des Paketbaus benötigt

Falls Sie eine bestimmte Locale während des Baus benötigen, können Sie mittels dieses Tricks eine temporäre Datei erstellen:

Falls Sie LOCPATH auf die Entsprechung von /usr/lib/locale und LC_ALL auf den Namen der Locale setzen, die sie generieren, sollten Sie erreichen, was Sie möchten, ohne dass Sie Root sind. Etwas wie:

LOCALE_PATH=debian/tmpdir/usr/lib/locale
LOCALE_NAME=en_IN
LOCALE_CHARSET=UTF-8

mkdir -p $LOCALE_PATH
localedef -i $LOCALE_NAME.$LOCALE_CHARSET -f $LOCALE_CHARSET $LOCALE_PATH/$LOCALE_NAME.$LOCALE_CHARSET

# Using the locale
LOCPATH=$LOCALE_PATH LC_ALL=$LOCALE_NAME.$LOCALE_CHARSET date

6.8.7. Machen Sie Übergangspakete deborphan-konform

Deborphan ist ein Programm, das Anwendern hilft, Pakete aufzuspüren, die sicher vom System entfernt werden können, d.h. diejenigen, von denen keine Pakete abhängen. Die Standardoperation ist, nur innerhalb der Abschnitte "libs" und "oldlibs" zu suchen, um Jagd auf unbenutzte Bibliotheken zu machen. Wenn aber das richtige Argument übergeben wird, versucht es auch, andere nutzlose Pakete zu erkennen.

Mit --guess-dummy versucht``deborphan`` beispielsweise, alle Übergangspakete zu durchsuchen, die für ein Upgrade benötigt wurden, aber jetzt entfernt werden können. Hierzu wird derzeit in der Kurzbeschreibung nach der Zeichenkette dummy oder transitional gesucht. Es ist jedoch besser, nach beiden Zeichenketten zu suchen, da es einige Dummy- oder Übergangspakete gibt, die anderen Zwecken dienen.

Wenn Sie also solch ein Paket erstellen, achten Sie bitte darauf den Text transitional dummy package in der Kurzbeschreibung zu verwenden. Um nach Beispielen zu suchen, führen Sie einfach apt-cache search .|grep dummy oder apt-cache search .|grep transitional aus.

Außerdem wird empfohlen, den Abschnitt in oldlibs und die Priorität in optional zu ändern, um die Arbeit von deborphan zu erleichtern.

6.8.8. Optimale Vorgehensweisen für .orig.tar.{gz,bz2,xz}-Dateien

Es gibt zwei Arten von Original-Quell-Tarballs: unberührten Quellcode und neu paketierten Quellcode der Originalautoren.

6.8.8.1. Unberührter Quellcode

Das charakteristische Merkmal eines unberührten Tarballs ist, dass die .orig.tar.{gz,bz2,xz}-Datei Byte für Byte identisch mit einem offiziell weitergegebenen Tarball des Originalautors ist. [1] Dies ermöglicht die Benutzung von Prüfsummen, um auf einfache Weise alle Änderungen zwischen Debians Version und der der Originalautoren zu prüfen, die in der Diff-Datei in Debian enthalten sind. Falls außerdem der Originalquellcode riesig ist, können Originalautoren und andere, die bereits den Original-Tarball haben, Download-Zeit sparen, falls sie Ihre Paketierung im Detail inspizieren möchten.

Es gibt keine allgemein anerkannten Leitlinien, denen Originalautoren betreffend der Verzeichnisstruktur innerhalb ihres Tarballs folgen, aber dpkg-source ist dennoch in der Lage, mit den meisten Tarballs von Originalautoren als unberührtem Quellcode umzugehen. Seine Strategie entspricht dem Folgenden:

1. Es entpackt den Tarball in eine leeres temporäres Verzeichnis mittels

   zcat path/to/packagename_upstream-version.orig.tar.gz | tar xf -
   

2. Falls das temporäre Verzeichnis danach nur ein Verzeichnis und keine anderen Dateien enthält, benennt dpkg-source dieses Verzeichnis in Paketname_Originalversion(.orig) um. Der Name des Verzeichnisses auf der obersten Ebene im Tarball ist ohne Bedeutung und geht verloren.

3. Andernfalls muss der Tarball der Originalautoren ohne ein sonst übliches Verzeichnis der obersten Ebene gepackt worden sein (Schande über den Originalautor!). In diesem Fall benennt dpkg-source das temporäre Verzeichnis selbst in Paketname_Originalversion(.orig) um.

6.8.8.2. Neu paketierter Originalquellcode

Sie sollten Pakete, wenn möglich, mit einem unberührten Quell-Tarball hochladen, aber es gibt viele Gründe, warum das manchmal nicht möglich ist. Dies ist der Fall, wenn die Originalautoren den Quellcode gar nicht als Gzip-gepackte Tar-Datei weitergeben oder falls der Tarball der Originalautoren nicht-DFSG-freies Material enthält, das Sie vor den Hochladen entfernen müssen.

In diesen Fällen muss der Entwickler selbst eine geeignete .orig.tar.{gz,bz2,xz}-Datei bauen. Solch einen Tarball nennen wir neu paketierten Originalquellcode. Beachten Sie, dass sich neu paketierter Originalquellcode von einem nativen Debian-Paket unterscheidet. Eine neu paketierte Quelle kommt mit Debian-spezifischen Änderungen in einem separaten .diff.gz oder .debian.tar.{gz,bz2,xz} daher und hat eine Versionsnummer, die sich aus der Originalversion und der Debian-version zusammensetzt.

Es könnte Gründe geben, aus denen es wünschenswert wäre, den Quellcode neu zu paketieren, obwohl die Originalautoren ein .tar.{gz,bz2,xz} verteilen, dass im Prinzip in seiner unberührten Form benutzt werden könnte. Der naheliegendste Grund ist, wenn signifikante Platzersparnis durch Neukomprimierung des Tar-Archivs oder Entfernen von wirklich nutzlosem Müll aus dem Qriginalarchiv erzielt werden kann. Handeln Sie hier nach eigenem Ermessen, aber seien Sie darauf vorbereitet, Ihre Entscheidung zu verteidigen, falls Sie einen Quellcode neu paketieren, der unberührt sein könnte.

Ein neu paketiertes .orig.tar.{gz,bz2,xz} Archiv

1. sollte im resultierenden Quellpaket dokumentiert werden. Detaillierte Informationen darüber, wie die neu gepackte Quelle erhalten wurde und wie diese reproduziert werden kann, sollten in debian/copyright bereitgestellt werden, idealerweise auf eine Weise, die automatisch mit uscan durchgeführt werden kann. Wenn das wirklich nicht funktioniert, stellen Sie zumindest ein get-orig-source Target in Ihrer debian/rules Datei bereit, das den Vorgang wiederholt, auch wenn dies in der Version 4.1.4 Debian Policy als veraltet markiert worden ist.

2. sollte keine Datei enthalten, die nicht von dem/den Originalautor(en) stammt oder deren Inhalt von Ihnen geändert wurde. [2]

3. sollte außer, wenn es aus rechtlichen Gründen unmöglich ist, die ganze Erstellungs- und Portierungsinfrastruktur aufbewahren, die vom Originalautor bereitgestellt wurde. Es ist zum Beispiel kein ausreichender Grund für das Weglassen einer Datei, wenn sie nur für die Erstellung unter MS-DOS benutzt wird. Gleichermaßen sollte ein Makefile, das vom Originalautor bereitgestellt wurde, nicht einmal dann weggelassen werden, wenn das erste, was Ihre debian/rules tut, das Überschreiben durch Ausführen eines Konfigurationsskripts ist.

   (Begründung: Es ist üblich für Debian-Anwender, die Software für nicht-Debian-Plattformen erstellen möchten, den Quellcode von einem Debian-Spiegel abzurufen, anstatt den Speicherort der ordnungsgemäßen Originaldistribution zu suchen).

4. sollte das Schema Paketname-Upstream-Version+dfsg (oder ein beliebiges Attributs-Suffix, das dem Tarball-Namen hinzugefügt wird) als Name für das Verzeichnis der obersten Ebene in seinem Tarball benutzen .

5. sollte mit xz (oder gzip oderr bzip) und mit der maximalen Komprimierung gepackt werden.

6.8.8.3. Ändern binärer Dateien

Manchmal ist es nötig, binäre Dateien zu ändern, die im Original-Tarball enthalten sind oder binäre Dateien hinzuzufügen, die nicht darin enthalten sind. Dies wird vollständig unterstützt, wenn Sie Quellpakete im Format "3.0 (quilt)" benutzen. Lesen Sie die Handbuchseite dpkg-source1, um weitere Einzelheiten zu erfahren. Wenn Sie das ältere Format "1.0" benutzen, können binäre Dateien nicht im .diff.gz gespeichert werden, daher müssen Sie eine mit uuencode (oder ähnlichem) kodierte Version der Datei(en) speichern und zur Erstellungszeit in debian/rules entschlüsseln (und an ihren offiziellen Platz verschieben).

6.8.9. Optimale Vorgehensweisen für Debug-Pakete

Ein Debug-Paket ist ein Paket, das zusätzliche Informationen enthält, die von gdb verwendet werden können. Da Debian diese Zusatzinformationen in Binärdateien standardmäßig entfernt, sind Debugging-Informationen wie Funktionsnamen und Zeilennummern dann nicht mehr verfügbar, wenn gdb auf Debian-Binärdateien ausgeführt wird. Mit Debug-Paketen können Benutzer, die diese zusätzlichen Debugging-Informationen benötigen, diese installieren, ohne ein reguläres System mit den in der Regel recht Speicherplatz intensiven Informationen aufzublähen.

Die Debug-Pakete enthalten separate Debugging-Symbole, die gdb beim Debuggen eines Programms oder einer Bibliothek im laufenden Betrieb finden und laden kann. Die Konvention in Debian besteht darin, diese Symbole in /usr/lib/debug /path abzulegen, wobei path der Pfad zur ausführbaren Datei oder Bibliothek ist. Zum Beispiel gehen Debugging-Symbole für /usr/bin/foo nach /usr/lib/debug/usr/bin/foo und Debugging-Symbole für /usr/lib/libfoo.so.1 gehen nach /usr/lib/debug/usr/lib/libfoo.so.1.

6.8.9.1. Automatisch erstellte Debug-Pakete

Debug-Symbolpakete können automatisch für jedes Binärpaket, das ausführbare Binärdateien enthält, generiert werden. Mit Ausnahme von Sonderfällen sollte es nicht mehr erforderlich sein, die alten manuell generierten zu verwenden. Der Paketname für ein automatisch generiertes Debug-Symbolpaket endet mit -dbgsym.

Die dbgsym-Pakete werden nicht in die regulären Archiven installiert, sondern in dedizierte Archive. Das heißt, wenn Sie die Debug-Symbole zum Debuggen benötigen, müssen Sie diese Archive zu Ihrer apt-Konfiguration hinzufügen und dann das entsprechende dbgsym-Paket installieren an dem Sie interessiert sind. Bitte lesen Sie https://wiki.debian.org/HowToGetABacktrace um mehr zu diesem Thema zu erfahren.

6.8.9.2. Manuelle -dbg Pakete

Vor dem Aufkommen der automatischen dbgsym-Pakete mussten Debug-Pakete manuell generiert werden. Der Name eines manuellen Debug-Pakets endet auf -dbg. Es wird empfohlen solche alten Legacy-Pakete nach Möglichkeit auf die neuen dbgsym-Pakete zu migrieren. Das Verfahren zum Konvertieren Ihres Pakets ist unter https://wiki.debian.org/AutomaticDebugPackages beschrieben. Im Wesentlichen wird jedoch der Schalter --dbgsym-migration = 'pkgname-dbg (<< currentversion~)' durch den Befehl dh_strip verwendet.

Manchmal ist es jedoch nicht möglich auf die neuen dbgsym-Pakete zu konvertieren, oder Sie werden auf die alten manuellen -dbg-Pakete in den Archiven stoßen, sodass Sie sich möglicherweise mit ihnen befassen müssen. Es wird nicht empfohlen, manuelle -dbg-Pakete für neue Pakete zu erstellen, es sei denn, die automatische Erstellung funktioniert aus irgendeinem Grund nicht.

Ein Grund könnte sein, dass Debug-Pakete einen ganzen speziellen Debugging-Build einer Bibliothek oder einer anderen Binärdatei enthalten. Normalerweise reicht es jedoch aus, Debugging-Informationen von den bereits erstellten Binärdateien zu trennen, dies spart zusätzlich Platz und Erstellungszeit.

Dies ist beispielsweise der Fall bei Debugging-Symbolen von Python-Erweiterungen. Derzeit ist der richtige Weg, um Python-Erweiterungs-Debug-Symbole zu verpacken, die Verwendung von -dbg-Paketen, wie unter https://wiki.debian.org/Python/DbgBuilds beschrieben.

Um -dbg-Pakete erstellen zu können müssen diese explizit in der Datei debian/control aufgeführt werden.

Die Debugging-Symbole können mit objcopy --only-keep-debug aus einer Objektdatei extrahiert werden. Dann kann die Objektdatei entfernt und objcopy --add-gnu-debuglink verwendet werden, um den Pfad zur Debugging-Symboldatei anzugeben. objcopy 1 erklärt ausführlich, wie das funktioniert.

Beachten Sie, dass Debug-Pakete von dem Paket abhängen sollten, für das Sie Debugging-Symbole bereitstellen und diese Abhängigkeit sollte mit einer Version versehen werden. Zum Beispiel:

Depends: libfoo (= ${binary:Version})

Der Befehl dh_strip in debhelper unterstützt das Erstellen von Debug-Paketen und kann die Benutzung von objcopy übernehmen, um die Debugging-Symbole für Sie zu filtern. Wenn Ihr Paket debhelper/9.20151219 oder neuer verwendet, müssen Sie nichts zusätzliches tun. debhelper generiert Debug-Symbol-Pakete (mit dem Schema Paket-dbgsym) für Sie ohne zusätzliche Änderungen an Ihrem Quellpaket.

6.8.10. Optimale Vorgehensweisen für Meta-Pakete

Ein Meta-Paket ist meist ein leeres Paket, das es vereinfacht, eine Zusammenstellung von Paketen zu installieren, die sich im Lauf der Zeit weiterentwickeln können. Dies wird erreicht, indem das Metapaket von allen Paketen der Zusammenstellung abhängt. Dank der Fähigkeiten von APT kann der Betreuer des Meta-Pakets die Abhängigkeiten anpassen und das System des Anwenders wird automatisch die zusätzlichen Pakete erhalten. Die weggelassenen Pakete, die automatisch installiert wurden, werden außerdem als Kandidaten für das Entfernen gekennzeichnet (und werden sogar durch aptitude automatisch entfernt). gnome und linux-image-amd64 sind zwei Beispiele für Meta-Pakete (gebaut durch die Quellpakete meta-gnome2 und linux-latest).

Die ausführliche Beschreibung des Meta-Pakets muss dessen Zweck klar dokumentieren, so dass die Benutzer wissen was sie verlieren, wenn sie das Paket entfernen. Es wird empfohlen, genau über die Auswirkungen zu informieren. Dies ist besonders für Meta-Pakete wichtig, die während der anfänglichen Installation installiert werden und nicht explizit durch den Benutzer installiert wurden. Diese sind oft wichtig für das reibungslose Upgrade des Systems und der Benutzer sollte davon abgehalten werden, diese zu entfernen, um mögliche Schäden zu vermeiden.

[1]

Originalautoren können nicht daran gehindert werden, den von ihnen verteilten Tarball zu ändern, ohne die Versionsnummer zu erhöhen. Daher kann nicht gewährleistet werden, dass ein unberührter Tarball mit dem identisch ist, was die Originalautoren aktuell zu irgendeinem Zeitpunkt verteilen. Alles was erwartet werden kann, ist, dass es identisch mit etwas ist, das die Originalautoren einmal verteilt haben. Falls sich später ein Unterschied ergibt (etwa, wenn die Originalautoren merken, dass sie in ihrer Verteilung des Originals keine maximale Komprimierung nutzten und es dann erneut mit gzip packen), ist das einfach Pech. Da es keine brauchbare Möglichkeit gibt, ein neues .orig.tar.{gz,bz2,xz} für die gleiche Version hochzuladen, ist es sinnlos, dies als Fehler zu behandeln.

[2]

Als besondere Ausnahme könnte, falls das Auslassen unfreier Dateien dazu führen würde, dass das Build des Quellcodes ohne Unterstützung aus dem Debian-Diff fehlschlägt, das Bearbeiten der Dateien anstelle des Weglassens unfreier Teile davon und/oder Erklären der Situation in einer README.source-Datei im Wurzelverzeichnis des Quelltextes angemessen sein. Drängen Sie in diesem Fall aber den Originalautor dazu, die unfreien Komponenten leichter von dem restlichen Quelltext separierbar zu machen.

7. Jenseits von Paketierung

Debian ist weit mehr als nur Software zu paketieren und diese Pakete zu verwalten. Dieses Kapitel enthält Informationen über Wege, oft wirklich kritische Wege, fernab von einfachem Erstellen und Verwalten von Paketen zu Debian beizutragen.

Als eine Organisation von Freiwilligen verlässt sich Debian auf das Ermessen der Auswahl seiner Mitglieder, woran sie arbeiten möchten und was aus deren Sicht die kritischste Sache ist, in die sie Zeit investieren.

7.1. Fehler berichten

Bitte reichen Sie Fehlerberichte ein, wenn Sie Fehler in Debian-Paketen finden. Tatsächlich bilden Debian-Entwickler oftmals die erste Reihe der Tester. Fehler in den Paketen anderer Entwickler zu finden und zu melden, erhöht die Qualität von Debian.

Lesen Sie die Anweisungen zum Melden von Fehlern in der Debian-Fehlerdatenbank.

Versuchen Sie, den Fehlerbericht von einem normalen Benutzerkonto zu senden, auf dem Sie wahrscheinlich E-Mails empfangen können, so dass Leute, die weitere Informationen über den Fehler benötigen, Sie erreichen können. Senden Sie keine Fehlerberichte als Root.

Sie können ein Werkzeug wie reportbug 1 benutzen, um Fehlerberichte zu senden. Es kann den Prozess automatisieren und generell erleichtern.

Prüfen Sie, dass der Fehlerbericht nicht bereits schon gegen das Paket eingereicht wurde. Jedes Paket hat eine Fehlerliste, die einfach unter https://bugs.debian.org/Paketname einsehbar ist. Hilfswerkzeuge wie querybts 1 können Sie ebenfalls mit diesen Informationen versorgen (und reportbug wird normalerweise auch vor dem Versenden querybts aufrufen).

Versuchen Sie, Ihre Fehlerberichte an die ordnungsgemäße Stelle zu lenken. Wenn Ihr Fehlerbericht zum Beispiel von einem Paket handelt, das Dateien eines anderen Pakets überschreibt, prüfen Sie die Fehlerliste beider Pakete, um das Einreichen doppelter Fehlerberichte zu vermeiden.

Um zusätzliche Anerkennung zu erhalten, vereinigen Sie Fehler, die mehr als einmal berichtet wurden oder kennzeichnen Sie Fehler als "fixed", die bereits behoben wurden. Beachten Sie, dass Sie den Fehlerbericht nicht tatsächlich schließen sollten wenn Sie weder der Absender des Fehlers noch der Betreuer des Pakets sind (es sei denn, Sie versichern sich der Erlaubnis des Betreuers).

Von Zeit zu Zeit möchten Sie vielleicht prüfen, was aus den Fehlerberichten geworden ist, die Sie versandt haben. Nutzen Sie diese Gelegenheit, um diejenigen zu schließen, die Sie nicht mehr reproduzieren können. Um herauszufinden, welche Fehlerberichte Sie versandt haben, besuchen Sie https://bugs.debian.org/from:Ihre-E-Mail-Adresse.

7.1.1. Viele Fehler auf einmal berichten (Masseneinreichung von Fehlern)

Das Berichten einer großen Anzahl von Fehlern für dasselbe Problem für eine große Zahl von Paketen — d.h. mehr als zehn — ist eine nicht erwünschte Vorgehensweise. Unternehmen Sie alle nötigen Schritte, um das massenhafte Versenden von Fehlerberichten tunlichst zu vermeiden. Prüfen Sie zum Beispiel, ob das Problem automatisiert werden kann, indem Sie eine neue Prüfung zu lintian hinzufügen, so dass eine Fehlermeldung oder Warnung ausgegeben wird.

Falls Sie mehr als zehn Fehler auf einmal zum gleichen Thema berichten, wird empfohlen, dass Sie eine E-Mail an debian-devel@lists.debian.org senden, in der Sie Ihre Absichten darlegen, bevor Sie den Bericht versenden und die Tatsache im Betreff Ihrer Mail erwähnen. Dies wird anderen Entwicklern ermöglichen zu prüfen, ob der Fehler ein echtes Problem darstellt. Zusätzlich wird es helfen, eine Situation zu vermeiden, in der mehrere Betreuer simultan beginnen, den gleichen Fehlerbericht einzureichen.

Bitte benutzen Sie das Programm dd-list und falls geeignet whodepends (aus dem Paket devscripts), um eine Liste aller betroffenen Pakete zu generieren und fügen sie die Ausgabe in Ihre Mail an debian-devel@lists.debian.org ein.

Beachten Sie, wenn Sie viele Fehlerberichte mit dem gleichen Betreff senden möchten, dass Sie den Fehlerbericht an maintonly@bugs.debian.org senden sollten, so dass der Fehlerbericht nicht an die Fehlerverteilungs-Maillingliste weitergeleitet wird.

Das Programm mass-bug (aus dem Paket devscripts) kann benutzt werden um Bugreports gegen eine Liste von Paketen zu öffnen.

7.1.1.1. Usertags

Vielleicht möchten Sie BTS-Usertags (benutzerdefinierte Kennzeichnungen) benutzen, wenn Sie Fehlerberichte an eine größere Anzahl Pakete senden. Diese Kennzeichnungen sind den normalen Kennzeichen wie "patch" oder "wishlist" ähnlich, unterscheiden sich aber darin, dass sie benutzerdefiniert sind und einen Namensraum belegen, der einzigartig für einen bestimmten Benutzer ist. Dies ermöglicht mehreren Gruppierungen von Entwicklern, den gleichen Fehler benutzerdefiniert auf unterschiedliche Arten zu kennzeichnen, ohne Konflikte zu verursachen.

Um beim Einreichen von Fehlerberichten Usertags hinzuzufügen, geben Sie die Pseudokopfzeilen User und Usertags an:

To: submit@bugs.debian.org
Subject: title-of-bug

Package: pkgname
[ ... ]
User: email-addr
Usertags: tag-name [ tag-name ... ]

description-of-bug ...

Beachten Sie, dass Kennzeichnungen durch Leerzeichen getrennt werden und keine Unterstriche enthalten dürfen. Falls Sie Fehlerberichte für eine spezielle Gruppe oder ein Team einreichen, wird empfohlen, dass Sie bei User eine passende Mailingliste eintragen, nachdem Sie Ihre Absicht dort geschildert haben.

Um Fehler mit einem bestimmten Usertag anzusehen, benutzen Sie https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=E-Mail-Adresse&tag=Kennzeichen.

7.2. Qualitätssicherungsbestreben

7.2.1. Tägliche Arbeit

Auch wenn es eine eigene Gruppe für Qualitätssicherung gibt, sind QS-Aufgaben nicht ausschließlich dieser Gruppe vorbehalten. Sie können sich an dieser Aufgabe beteiligen, indem Sie Ihre Pakete so fehlerfrei und lintian-rein (siehe lintian) wie möglich halten. Falls Sie finden, dies sei unmöglich, dann sollten Sie darüber nachdenken, einige Ihrer Pakete zu verwaisen (siehe Verwaisen von Paketen). Alternativ könnten Sie andere Leute um Hilfe bitten, um den Rückstand, den Sie bei den Fehlern haben, aufzuholen (Sie können auf debian-qa@lists.debian.org oder debian-devel@lists.debian.org nach Hilfe fragen). Gleichzeitig können Sie sich nach Mitbetreuern umsehen (siehe Gemeinschaftliche Verwaltung).

7.2.2. Treffen zur gemeinschaftlichen Behebung von Fehlern (Bug-Squashing-Partys)

Von Zeit zu Zeit organisiert die QS-Gruppe Bug-Squashing-Partys, um so viele Probleme wie möglich zu beseitigen. Sie werden auf debian-devel-announce@lists.debian.org angekündigt und in der Ankündigung wird erklärt, auf welchem Bereich der Fokus der Party liegt: Üblicherweise konzentriert man sich auf Release-kritische Fehler, aber es kann auch vorkommen, dass entschieden wird, bei der Fertigstellung eines Haupt-Upgrades zu helfen (wie einer neuen perl-Version, die ein Neukompilieren aller binären Module erfordert).

Die Regeln für Non-Maintainer-Uploads unterscheiden sich während der Parties, da die Ankündigung der Party als vorausgehende Ankündigung für den NMU angesehen wird. Falls Sie Pakete haben, die von der Party betroffen sind (da sie zum Beispiel Release-kritische Fehler enthalten), sollten Sie eine Aktualisierung zu jedem zugehörigen Fehler senden, um seinen aktuellen Status zu erklären und was Sie von der Party erwarten. Falls Sie keinen NMU möchten, nicht an einem Patch interessiert sind oder den Fehler selbst bewältigen möchten, erklären Sie dies bitte im BTS.

Teilnehmer der Party haben besondere Regeln für NMUs. Sie können NMUs ohne vorherige Ankündigung durchführen, falls sie mindestens nach DELAYED/3-day hochladen. Alle anderen NMU-Regeln gelten wie üblich; sie sollten den Patch des NMUs an das BTS senden (an einen der offenen Fehler, der durch den NMU behoben wird oder an einen neuen Fehler, der als "fixed" gekennzeichnet wird). Sie sollten außerdem die besonderen Wünsche des Betreuers respektieren.

Falls Sie sich nicht sicher fühlen, einen NMU durchzuführen, senden Sie nur einen Patch an das BTS. Das ist weitaus besser als ein beschädigter NMU.

7.3. Andere Paketbetreuer kontaktieren

Während Ihres Lebens innerhalb von Debian werden Sie aus verschiedenen Gründen Kontakt zu anderen Betreuern haben. Sie möchten vielleicht neue Wege der Kooperation zwischen einer Zusammenstellung verwandter Pakete diskutieren oder einfach jemanden daran erinnern, dass eine neue Originalversion verfügbar ist, die Sie benötigen.

Die E-Mail-Adresse eines Paketbetreuers heraussuchen zu müssen, kann störend sein. Glücklicherweise gibt es einen einfachen E-Mail-Alias, Paket@packages.debian.org, der eine Möglichkeit bietet, dem Betreuer eine Mail zu schicken, ganz gleich wie seine E-Mail-Adresse (oder Adressen) auch sein mag. Ersetzen Sie Paket durch den Namen eines Quell- oder Binärpakets.

Möglicherweise sind Sie außerdem daran interessiert, Personen zu kontaktieren, die ein bestimmtes Quellpaket mittels Das Debian-Paketverfolgungssystem abonniert haben. Sie können dazu die E-Mail-Adresse Paket@packages.qa.debian.org benutzen.

7.4. Sich mit inaktiven und/oder nicht erreichbaren Paketbetreuern beschäftigen

Falls Sie bemerken, dass es einem Paket an Pflege mangelt, sollten Sie prüfen, dass der Betreuer aktiv ist und weiter an seinen Paketen arbeitet. Es ist möglich, dass er nicht mehr aktiv ist, sich aber nicht aus dem System abgemeldet hat. Andererseits ist es auch möglich, dass er nur eine Erinnerung braucht.

Es gibt ein einfaches System (die MIA-Datenbank), in der Informationen über Paketbetreuer aufgezeichnet werden, die als "Missing In Action" (vermisst) gelten. Wenn ein Mitglied der QS-Gruppe einen inaktiven Betreuer kontaktiert oder weitere Informationen über ihn findet, wird dies in der MIA-Datenbank aufgezeichnet. Das System ist unter /org/qa.debian.org/mia auf dem Rechner qa.debian.org verfügbar und kann mit dem Werkzeug mia-query abgefragt werden. Benutzen Sie mia-query --help, um zu erfahren, wie Sie Abfragen an die Datenbank richten. Falls Sie der Meinung sind, dass noch keine Informationen über einen inaktiven Betreuer aufgezeichnet wurde oder dass Sie weitere Informationen hinzufügen können, sollten Sie im Allgemeinen wie folgt verfahren.

Im ersten Schritt kontaktieren Sie den Betreuer höflich und warten eine angemessene Zeit auf eine Antwort. Es ist ziemlich schwer zu definieren, was eine angemessene Zeit ist, aber es ist wichtig zu berücksichtigen, dass das wahre Leben manchmal sehr hektisch ist. Eine Möglichkeit damit umzugehen wäre es, nach zwei Wochen eine Erinnerung zu senden.

Eine nicht funktionierende E-Mail-Adresse ist eine Verletzung der Debian Richtlinien. Falls eine E-Mail nicht zustellbar ist, melden Sie dies bitte als einen Fehler gegen das Paket, und informieren Sie das MIA-Team.

Falls der Betreuer nicht innerhalb von vier Wochen (einem Monat) antwortet, kann davon ausgegangen werden, dass wahrscheinlich keine Antwort mehr kommt. Falls dies geschieht, sollten Sie weiter nachforschen und versuchen so viele nützliche Informationen wie möglich über den betreffenden Betreuer zu sammeln. Dies beinhaltet:

• Die echelon-Informationen, die über debian.org Developers LDAP Search verfügbar sind. Sie geben an, wann der Entwickler zum letzten Mal an eine Debian-Mailingliste geschrieben hat. (Dies umfasst auch Mails über Uploads, die über die Liste debian-devel-changes@lists.debian.org verteilt wurden.) Denken Sie außerdem daran zu prüfen, ob der Betreuer in der Datenbank als im Urlaub befindlich markiert ist.

• Die Anzahll der Pakete, für die dieser Betreuer verantwortlich ist und den Zustand dieser Pakete. Hauptsächlich, ob es Release-kritische Fehler gibt, die seit Jahren offen sind. Ferner wie viele Fehler es im Allgemeinen sind. Ein weiterer wichtiger Teil der Informationen ist, ob für die Pakete NMUs durchgeführt werden und wenn von wem.

• Gibt es irgendeine Aktivität des Betreuers außerhalb von Debian? Er könnte zum Beispiel aktuell etwas an eine Nicht-Debian-Mailingliste oder an Newsgroups geschrieben haben.

Ein ziemliches Problem sind Pakete, die gesponsert wurden — der Betreuer ist kein offizieller Debian-Entwickler. Die echelon-Informationen sind nicht für gesponserte Leute verfügbar, so dass Sie beispielsweise den Debian-Entwickler finden und kontaktieren müssen, der das Paket tatsächlich hochgeladen hat. Angenommen, das Paket wurde signiert, dann ist er dennoch für das Paket verantwortlich und weiß wahrscheinlich, wie es mit der Person aussieht, für die er das Paket sponserte.

Es ist außerdem erlaubt, eine Anfrage an debian-devel@lists.debian.org zu senden und zu fragen, ob jemand etwas über den Verbleib des vermissten Betreuers weiß. Bitte senden Sie der Person, um die es geht, per Cc: eine Kopie.

Sobald Sie all dies gesammelt haben, können Sie mia@qa.debian.org kontaktieren. Die Leute hinter diesem Alias werden die von Ihnen bereitgestellten Informationen nutzen, um zu entscheiden, wie verfahren wird. Beispielsweise könnten sie eines oder alle Pakete des Betreuers verwaisen. Falls für ein Paket ein NMU durchgeführt wurde, könnten sie es vorziehen, vor dem Verwaisen des Pakets denjenigen zu kontaktieren, von dem der NMU durchgeführt wurde — vielleicht ist diese Person daran interessiert, das Paket zu übernehmen.

Eine abschließende Bemerkung: Bitte denken Sie daran immer höflich zu bleiben. Alle hier sind Freiwillige und können nicht sämtliche Zeit Debian widmen. Außerdem wissen Sie nichts über die Situation der beteiligten Person. Vielleicht ist sie ernsthaft erkrankt oder sogar verstorben — Sie wissen nicht, wer auf der Empfängerseite ist. Stellen Sie sich vor, wie sich ein Verwandter fühlt, wenn er die E-Mail des Verstorbenen liest und eine sehr unhöfliche, böse oder vorwurfsvolle Nachricht findet!

Andererseits, trotz dass wir alle Freiwillige sind, geht ein Paketbetreuer auch eine Verpflichtung ein und hat deshalb auch eine Verantwortung, das Paket zu pflegen. So können Sie die Wichtigkeit eines übergeordneten Wohls betonen — falls die Betreuer keine Zeit oder kein Interesse mehr haben, sollten sie loslassen und das Paket jemandem mit mehr Zeit übergeben.

Wenn Sie Interesse daran haben im MIA Team mitzuarbeiten dann schauen Sie bitte in die Datei README` in /org/qa.debian.org/mia auf qa.debian.org. In dieser Datei sind die technischen Details als auch der MIA Prozess dokumentiert. Zur Kontaktaufnahme mit dem MIA Team schreiben Sie bitte an E-Mail an mia@qa.debian.org.

7.5. Zusammenwirken mit zukünftigen Debian-Entwicklern

Debians Erfolg hängt von der Fähigkeit ab, neue und talentierte Entwickler für das Projekt zu gewinnen und auch zu halten. Wenn Sie ein erfahrener Entwickler sind, wird Ihnen empfohlen, sich am Prozess neue Entwickler heranzuziehen zu beteiligen.

7.5.1. Pakete sponsern

Sponsern eines Pakets bedeutet, ein Paket für einen Betreuer hochzuladen, der nicht in der Lage ist, dies selbst zu tun. Es ist keine belanglose Angelegenheit, der Sponsor muss die Paketierung überprüfen und dafür sorgen, dass sie der hohen Qualität entspricht, die Debian anstrebt.

Debian-Entwickler können Pakete sponsoren. Debian-Betreuer können dies nicht.

Der Prozess, ein Paket zu sponsern ist:

1. Der Betreuer bereitet ein Quellpaket (.dsc) vor und legt dies Online ab (z.B. auf mentors.debian.net) oder besser, er verweist auf ein öffentlich zugängliches VCS Repository (siehe salsa.debian.org: Git Repositorys und kollaborative Entwicklungsplattform) in dem das Paket verwaltet wird.

2. Der Sponsor lädt das Quellpaket herunter (oder führt einen Checkout durch).

3. Der Sponsor prüft das Quellpaket. Falls er Probleme entdeckt, informiert er den Betreuer und bittet ihn, eine korrigierte Version bereitzustellen (der Prozess beginnt von vorn mit dem ersten Schritt).

4. Der Sponsor konnte kein verbliebenes Problem finden. Er erstellt das Paket, signiert es und lädt es nach Debian hoch.

Bevor Sie die Einzelheiten erforschen, wie ein Paket gesponsert wird, sollten Sie sich selbst fragen, ob das vorgeschlagene Paket einen Mehrwert für Debian und dessen Nutzer bringt.

Es gibt keine einfache Regel, um diese Frage zu beantworten, sie kann von vielen Faktoren abhängen: Ist die Code-Basis der Originalautoren ausgereift und nicht voller Sicherheitslücken? Gibt es bereits existierende Pakete, die die gleiche Aufgabe erledigen können und wie sind diese im Vergleich zu diesem neuen Paket? Gab es für dieses neue Paket eine Nachfrage durch Anwender und wie groß ist die Benutzerbasis? Wie aktiv sind die Entwickler des Originalsoftware?

Sie sollten außerdem sicherstellen, dass der zukünftige Betreuer ein guter Betreuer sein wird. Hat er bereits etwas Erfahrung mit anderen Paketen? Falls ja, leistet er bei ihnen gute Arbeit (überprüfen Sie einige Fehlerberichte)? Ist er vertraut mit dem Paket und dessen Programmiersprache? Verfügt er über die für dieses Paket nötigen Fähigkeiten? Falls nicht: ist er in der Lage, sie zu erlernen?

Es ist auch eine gute Idee zu wissen, wo der neue Betreuer im Bezug zu Debian steht: Stimmt er Debians Philosophie zu und beabsichtigt sich der Debian Gemeinschaft anzuschließen? Angesichts der Tatsache, wie einfach es ist, Debian-Mitglied zu werden, möchten Sie möglicherweise nur Personen sponsern, die eine Mitgliedschaft planen. Auf diese Weise wissen Sie von Anfang an, dass Sie nicht auf unbestimmte Zeit als Sponsor auftreten müssen.

7.5.1.1. Ein neues Paket sponsern

Neue Betreuer haben gewöhnlich bestimmte Schwierigkeiten bei der Erstellung von Debian-Paketen — dies ist ziemlich verständlich. Sie werden nicht immer alles richtig machen. Das ist der Grund, weshalb das Sponsern eines brandneuen Pakets in Debian eine sorgfältige Überprüfung notwendig macht. Manchmal sind mehrere Wiederholungen nötig, bis das Paket gut genug ist, um ins Debian Archive geladen werden zu können. Daher impliziert ein Sponsor zu sein ebenfalls auch ein Mentor zu sein.

Sponsern Sie ein Paket nie, ohne es zu überprüfen. Die Überprüfung eines neuen Pakets, die von den Ftpmasters vorgenommen wird, stellt nur sicher, dass die Software wirklich frei ist. Natürlich kommt es vor, dass sie über Paketierungsprobleme stolpern, aber das sollte wirklich nicht passieren. Es ist Ihre Aufgabe, dafür zu sorgen, dass das hochgeladene Paket mit Debians Richtlinien für freie Software übereinstimmt und von guter Qualität ist.

Das Erstellen des Pakets und Prüfen der Software ist Teil der Überprüfung, aber es reicht nicht aus. Der Rest dieses Abschnitts enthält eine unvollständige Liste von Punkten, die Sie bei Ihrer Überprüfung testen sollten. [1]

• Prüfen Sie, ob der bereitgestellte Original-Tarball derselbe ist wie der, den der Originalautor verteilt (wenn die Quellen neu für Debian gepackt wurden, erstellen Sie selbst den geänderten Tarball).

• Führen Sie lintian aus (siehe lintian). Sie werden so gängige Probleme finden. Verifizieren Sie, dass jegliche lintian-overrides des Betreuers vollständig gerechtfertigt sind.

• Führen Sie licensecheck aus (Teil von devscripts) und überprüfen Sie, ob debian/copyright korrekt und komplett zu sein scheint. Suchen Sie nach Lizenzproblemen (wie Dateien mit "All rights reserved"-Kopfzeilen oder nicht DFSG-konformen Lizenzen). Bei dieser Aufgabe ist grep -ri Ihr Freund.

• Erstellen Sie das Paket mit pbuilder (oder einem ähnlichen Werkzeug, siehe pbuilder), um sicherzustellen, dass die Build-Abhängigkeiten vollständig sind.

• Lesen Sie debian/control Korrektur: Folgt es den optimalen Vorgehensweisen (siehe Optimale Vorgehensweisen für debian/control)? Sind die Abhängigkeiten vollständig?

• Lesen Sie debian/rules Korrektur: Folgt es den optimalen Vorgehensweisen (siehe Optimale Vorgehensweisen für debian/rules)? Sehen Sie mögliche Verbesserungen?

• Lesen Sie die Betreuerskripte (preinst, postinst, prerm, postrm, config) Korrektur: Werden preinst/postrm funktionieren, wenn die Abhängigkeiten nicht installiert sind? Sind alle Skripte idempotent (d.h. können sie ohne Konsequenzen mehrmals ausführt werden)?

• Überprüfen Sie jede Änderung an Originaldateien (entweder in .diff.gz, in debian/patches/ oder direkt in den Tarball debian für Binärdateien eingebettet). Sind sie gerechtfertigt? Sind sie ordentlich dokumentiert (mit DEP-3 für Patches)?

• Fragen Sie sich für jede Datei, warum diese Datei dort ist und ob dies der richtige Weg ist, das gewünschte Ergebnis zu erzielen. Folgt der Betreuer den optimalen Vorgehensweisen beim Paketieren (siehe Optimale Vorgehensweise beim Paketieren)?

• Erstellen Sie die Pakete, installieren Sie sie und probieren Sie die Software aus. Stellen Sie sicher, dass Sie die Pakete entfernen und vollständig entfernen können. Testen Sie sie eventuell mit piuparts.

Falls die Kontrolle keine Probleme offenbarte, können Sie das Paket erstellen und nach Debian hochladen. Denken Sie daran, dass, obwohl Sie nicht der Betreuer sind, Sie als Sponsor trotzdem auch für das verantwortlich sind, was Sie nach Debian hochladen. Daher sollten Sie das Paket durch das Das Debian-Paketverfolgungssystem im Auge zu behalten.

Beachten Sie, dass Sie das Quellpaket nicht verändern sollten, um Ihren Namen in die Datei changelog oder control einzutragen. Das Feld Maintainer der Dateien control und changelog sollte die Person aufführen, die das Paket erstellte, d.h. den Gesponserten. Auf diese Art wird er die gesamten Nachrichten vom BTS erhalten.

Stattdessen sollten Sie dpkg-buildpackage anweisen, Ihren Schlüssel für die Signatur zu benutzen. Sie erreichen dies mit der Option -k:

dpkg-buildpackage -kKEY-ID

Falls Sie debuild und debsign benutzen, können sie das sogar permanent in ~/.devscripts konfigurieren:

DEBSIGN_KEYID=KEY-ID

7.5.1.2. Eine Aktualisierung eines existierenden Pakets sponsern

Sie werden normalerweise davon ausgehen, dass das Paket bereits eine vollständige Überprüfung durchlief. Daher werden Sie, anstatt dies nochmals erneut zu tun, nur die Unterschiede zwischen der aktuellen und der neu vom Betreuer vorbereiteten Version sorgsam analysieren. Falls Sie die anfängliche Überprüfung nicht selbst durchgeführt haben, könnten Sie auch noch einen genaueren Blick darauf werfen, nur für den Fall, dass der erste Prüfer nachlässig war.

Damit Sie die Unterschiede untersuchen können, benötigen Sie beide Versionen. Laden Sie die aktuelle Version des Quellpakets herunter (mit apt-get source) und erstellen Sie es (oder laden Sie die aktuellen Binärpakete mit aptitude download herunter). Laden Sie das Quellpaket zum Sponsern (üblicherweise mit dget).

Lesen Sie das Änderungsprotokoll, damit Sie wissen, was Sie während der Überprüfung erwartet. Das Hauptwerkzeug, das Sie benutzen werden, ist debdiff (bereitgestellt vom Paket devscripts). Sie können es mit zwei Quellpaketen (.dsc-Dateien), zwei Binärpaketen oder zwei .changes-Dateien (dann wird es alle Binärpakete vergleichen, die in .changes aufgeführt sind) ausführen.

Falls Sie die Quellpakete vergleichen (ausschließlich der Originaldateien im Fall einer neuen Originalversion, zum Beispiel durch Filtern der Ausgabe von debdiff mit filterdiff -i '*/debian/*'), müssen Sie alle Änderungen verstehen und sie sollten ordentlich im Debian-Änderungsprotokoll dokumentiert sein.

Falls alles in Ordnung ist, erstellen Sie das Paket und vergleichen Sie die Binärpakete, um zu prüfen, ob die Änderungen am Quellpaket keine unerwarteten Folgen haben (wie einige versehentlich entfallenen Dateien, fehlende Abhängigkeiten etc.)

Sie möchten möglicherweise das Package-Tracking-System nutzen (siehe Das Debian-Paketverfolgungssystem), um zu überprüfen, ob der Betreuer nichts wichtiges versäumt hat. Möglicherweise gibt es Übersetzungsaktualisierungen, die im BTS liegen und hätten integriert werden können. Möglicherweise wurde ein NMU des Pakets durchgeführt und der Betreuer vergaß, die Änderungen des NMUs in sein Paket einzubauen. Vielleicht ist ein Release-kritischer Fehler unbehandelt geblieben und dies blockiert die Migration nach Testing. Falls Sie etwas finden, was (besser) erledigt werden könnte, ist es an der Zeit, ihm dies mitzuteilen, so dass er es dies das nächste Mal besser machen kann und dass er seine Verantwortlichkeiten besser versteht.

Falls Sie kein bedeutendes Problem gefunden haben, laden Sie die neue Version hoch. Andernfalls bitten Sie den Betreuer, Ihnen eine korrigierte Version zur Verfügung zu stellen.

7.5.2. Einrichten von Uploadberechtigungen für DM

Ein Debian Developer kann Uploadberechtigungen an einem spezifischen Paket für einen Debian Maintainer einrichten sobald der Schlüssel des Debian Maintainers in den Debian Maintainer Schlüsselring aufgenommen worden ist. Dazu muss der Developer ein signiertes DAK-Kommando an ftp.upload.debian.org schicken wie in der FTP-Master Ankündigung an Debian-Devel beschrieben worden ist.

Dieser Prozess kann durch die Hilfe vom dcut Kommando aus dem Paket dput-ng vereinfacht werden. Hinweis, das funktioniert nicht mit dem dcut Kommando aus dem Paket dput!

Zum Beispiel:

dcut dm --uid 0xfedcba9876543210 --allow nano --deny bash

Wenn sich der Schlüssel des DM noch nicht im Paket vom Schlüsselring, aber im lokalen Schlüsselbund des DD befindet, verwenden Sie die Option „--force“ und den Fingerabdruck, ohne Leerzeichen und in diesem speziellen Fall ohne das Präfix 0x und ausschließlich in Großbuchstaben:

dcut --force dm --uid FEDCBA9876543210FEDCBA9876543210 --allow nano

7.5.3. Neue Entwickler befürworten

Lesen Sie die Seite Einen zukünftigen Entwickler befürworten auf der Debian-Website.

7.5.4. Handhabung von Bewerbungen neuer Betreuer

Lesen Sie bitte die Checkliste für Bewerbungsleiter auf der Debian-Website.

[1]

Sie können weitere Überprüfungen im Wiki finden, wo verschiedene Entwickler ihre eigenen Sponsoring-Prüflisten miteinander teilen.

8. Internationalisierung und Übersetzungen

Debian unterstützt eine immer größer werdende Zahl natürlicher Sprachen. Selbst wenn Englisch Ihre Muttersprache ist und Sie keine andere Sprache sprechen, gehört es zu Ihren Pflichten als Paketbetreuer, die Probleme der Internationalisierung zu kennen (abgekürzt I18n, weil 18 Buchstaben zwischen "i" und "n" im englischen Wort "internationalization" stehen). Daher sollten Sie sogar, wenn Sie mit rein englischen Programmen klarkommen, das meiste in diesem Kapitel lesen.

Gemäß der Einführung in I18n von Tomohiro KUBOTA bedeutet I18n (Internationalisierung) eine Veränderung von Software oder damit verbundener Technologien, so dass eine Software potentiell mehrere Sprachen, Gewohnheiten und so weiter in der Welt handhaben kann, während L10n (Lokalisierung) die Implementierung einer speziellen Sprache für eine bereits internationalisierte Software bedeutet.

L10n und I18n sind miteinander verbunden, aber die Schwierigkeiten bezogen auf jeweils eines davon sind sehr unterschiedlich. Es ist nicht wirklich schwer, einem Programm das Wechseln der Sprache zu erlauben, in dem Texte basierend auf den Benutzereinstellungen angezeigt werden, aber es verschlingt viel Zeit, diese Nachrichten tatsächlich zu übersetzen. Andererseits ist es trivial, die Zeichenkodierung einzustellen, aber den Code so anzupassen, dass mehrere Zeichenkodierungen benutzt werden können, ist ein wirklich großes Problem.

Abgesehen von den I18n-Problemen, für die keine allgemeine Anleitung gegeben werden kann, gibt es tatsächlich keine Infrastruktur für L10n innerhalb von Debian, die mit dem Buildd-Mechanismus für die Portierung vergleichbar ist. Daher muss die meiste Arbeit manuell erledigt werden.

8.1. Wie Übersetzungen in Debian gehandhabt werden

Die Handhabung der Übersetzung von Texten, die in Paketen enthalten sind, ist immer noch eine manuelle Aufgabe und der Prozess hängt von der Art des Textes ab, den Sie übersetzt sehen wollen.

Meistens wird für Programm-Nachrichten die gettext-Infrastruktur verwendet. Dabei werden die Übersetzungen oft direkt in den jeweiligen Projekten gepflegt, wie bei dem Free Translation Project, bei dem GNOME Translation Project oder bei dem KDE Localization Projekt. Die einzige zentrale Ressource bei Debian ist die zentrale Übersetzungsstatistik von Debian, wo Statistiken zu übersetzen Dateien gefunden und heruntergeladen werden können.

Für Paketbeschreibungen gibt es seit vielen Jahren Übersetzungen und Betreuer müssen nichts besonders tun um Übersetzungen von Paketbeschreibungen zu unterstützen, Übersetzer für Paketbeschreibungen sollten das Debian Übersetzungsprojekt für Beschreibungen (DDTP) benutzen.

Für debconf-Vorlagen sollten Betreuer das po-debconf-Paket verwenden, um die Arbeit von Übersetzern zu vereinfachen. Einige Statistiken können auf der Seite zur zentralen Übersetzungsstatistik von Debian gefunden werden.

Für Webseiten hat jedes L10n-Team Zugriff auf das passende VCS und die Statistiken sind auf der Site für die zentrale Übersetzungsstatistik von Debian verfügbar.

Für allgemeine Dokumentation über Debian entspricht der Prozess mehr oder weniger dem der Webseiten (für Übersetzer, die Zugriff auf das VCS haben), aber es gibt dort keine Statistikseiten.

Ein weiterer Teil der Internationalisierungsarbeit betrifft paketspezifische Dokumentation (Handbuchseiten, Info-Dokumente und andere Formate). Zumindest die Handbuchseiten werden mit po-Dateien übersetzt, wie die meisten anderen bereits erwähnten Dateien.

8.2. I18N & L10N FAQ für Paketbetreuer

Dies ist eine Liste von Problemen, denen Betreuer bezüglich I18n und L10n gegenüberstehen. Behalten Sie, während Sie dies lesen, im Hinterkopf, dass es über diese Punkte innerhalb von Debian keine Einigkeit gibt und folgendes nur ein Ratschlag sein kann. Falls Sie für die vorliegenden Probleme bessere Ideen haben oder mit einigen Punkten nicht einverstanden sind, tun Sie sich keinen Zwang an und geben Sie Ihre Rückmeldung, so dass dieses Dokument verbessert werden kann.

8.2.1. Wie ein vorliegender Text übersetzt wird

Um Paketbeschreibungen zu übersetzen, müssen Sie nichts tun. Die DDTP-Infrastruktur wird das zu übersetzende Material an Freiwillige schicken, ohne dass Sie dazu etwas tun müssen.

Für alle weiteren Dokumente (debconf-Vorlagen, gettext-Dateien, Handbuchseiten oder andere Dokumentation) sollte eine Anfrage für die Übersetzung in weitere Sprachen an debian-i18n geschrieben werden. Einige Mitglieder der Übersetzungs-Teams stehen auf der Liste und werden die weitere Koordinierung übernehme, um die Materialien übersetzt und gesichtet zu bekommen. Wenn die Übersetzungen fertig sind, werden Sie die übersetzten Dokumente per E-Mail oder per wishlist-Fehlerbericht bekommen. Es wird empfohlen die po-debconf-Werkzeuge für die I18n-Integration zu verwenden.

8.2.2. Wie eine vorliegende Übersetzung überprüft wird

Von Zeit zu Zeit übersetzen Einzelpersonen einige Texte in Ihrem Paket und bitten Sie, die Übersetzung in das Paket aufzunehmen. Dies kann problematisch werden, falls Sie die vorliegende Sprache nicht fließend sprechen. Es ist eine gute Idee, das Dokument an die entsprechende L10n-Mailingliste zu senden und um eine Überprüfung zu bitten. Sobald dies erledigt ist, sollten Sie von der Qualität der Übersetzug überzeugt sein und sich sicherer fühlen, sie in Ihr Paket einzubinden.

8.2.3. Wie eine vorliegende Übersetzung aktualisiert wird

Falls Sie einige Übersetzungen eines vorliegendens Textes herumliegen haben, sollten Sie jedesmal, wenn Sie das Original aktualisieren, den letzten Übersetzer bitten, die Übersetzung mit Ihren neuen Änderungen zu aktualisieren. Behalten Sie im Hinterkopf, dass diese Aufgabe Zeit beansprucht; mindestens eine Woche, um die Aktualisierung korrekturlesen zu lassen und so weiter.

Falls der Übersetzer nicht reagiert, könnten Sie auf der entsprechenden L10n-Mailingliste um Hilfe ersuchen. Falls alles scheitert, vergessen Sie nicht, eine Warnung im übersetzten Dokument zu hinterlassen, die angibt, dass die Übersetzung veraltet ist und der Leser sich, wenn möglich, auf das Originaldokument beziehen sollte.

Vermeiden Sie es, eine Übersetzung vollständig zu entfernen, weil sie veraltet ist. Veraltete Dokumentation ist für Leute, die kein Englisch sprechen, oft besser als gar keine Dokumentation.

8.2.4. Wie Fehlerberichte gehandhabt werden, die eine Übersetzung betreffen

Die beste Lösung ist wahrscheinlich, den Fehler als zu den Originalautoren weitergeleitet zu kennzeichnen und ihn sowohl an den letzten Übersetzer als auch an sein Team zu senden (unter Benutzung der entsprechenden debian-l10n-XXX-Mailingliste).

8.3. I18n- & L10n-FAQ für Übersetzer

Behalten Sie, während Sie dies lesen, im Hinterkopf, dass es über diese Punkte innerhalb von Debian keine Einigkeit gibt, und dass Sie auf jeden Fall mit Ihrem Team und dem Paketbetreuer zusammenarbeiten sollten.

8.3.1. Wie man bei Übersetzungsbemühungen helfen kann

Wählen Sie aus, was Sie übersetzen möchten und stellen Sie sicher, dass nicht bereits jemand daran arbeitet (benutzen Sie Ihre debian-l10n-XXX-Mailingliste), übersetzen Sie es, lassen Sie es durch andere mit dieser Muttersprache auf Ihrer L10n-Mailingliste überprüfen und stellen Sie es dem Paketbetreuer zur Verfügung (siehe nächsten Punkt).

8.3.2. Wie eine Übersetzung zur Eingliederung in ein Paket bereitgestellt wird

Stellen Sie sicher, dass Ihre Übersetzung korrekt ist (bitten Sie auf Ihrer L10n-Mailingliste um eine Überprüfung), bevor Sie sie zur Eingliederung bereitstellen. Es wird für jeden eine Zeitersparnis sein und das Chaos vermeiden, das daraus resultiert, dass Sie mehrere Versionen des gleichen Dokuments in Fehlerberichten haben.

Die beste Lösung ist es, einen regulären Fehlerbericht gegen das Paket einzureichen, der die Übersetzung enthält. Stellen Sie sicher, dass Sie die Kennzeichnung "patch", "l10n" und keinen Schweregrad höher als "wishlist" verwenden, da das Fehlen einer Übersetzung ein Programm niemals an der Ausführung hindert.

8.4. Beste aktuelle Vorgehensweise bezüglich L10n

• Bearbeiten Sie als Betreuer niemals die Übersetzungen in irgendeiner Weise (auch nicht, um das Aussehen neu zu formatieren), ohne mit der entsprechenden L10n-Mailingliste zu sprechen. Sie riskieren zum Beispiel, die Zeichenkodierung der Datei zu zerstören, wenn Sie dies tun. Außerdem könnte das, was Sie als Fehler betrachten, in der vorliegenden Sprache richtig sein (oder sogar nötig).

• Falls Sie als Übersetzer einen Fehler im Originaltext finden, stellen Sie sicher, dass er gemeldet wird. Übersetzer sind oft die aufmerksamsten Leser eines vorliegenden Textes und falls Sie die gefundenen Fehler nicht melden, wird es niemand tun.

• Denken Sie auf jeden Fall daran, dass der Hauptstreitpunkt bei L10n darin besteht, dass mehrere Leute für eine Zusammenarbeit nötig sind und dass es sehr leicht ist, selbst für kleine Probleme aufgrund von Missverständnissen einen Flame-War (schwerwiegende Streitigkeit) heraufzubeschwören. Falls Sie daher Probleme mit einem Gesprächspartner haben, fragen Sie auf der entsprechenden L10n-Mailingliste, Debian-I18n oder sogar Debian-Devel nach Hilfe (aber Vorsicht, L10n-Diskussionen führen auf jener Liste oft zu Flame-Wars :) ).

• Kooperation kann auf jeden Fall nur mit gegenseitigem Respekt erreicht werden.

1. Überblick über die Werkzeuge der Debian-Betreuer

Dieser Abschnitt enthält eine grobe Übersicht über die Werkzeuge, die Betreuern zur Verfügung stehen. Das Folgende ist beileibe nicht vollständig oder maßgeblich, sondern nur eine Anleitung für einige der beliebstesten Werkzeuge.

Debian-Betreuerwerkzeuge sind dazu gedacht, Entwicklern zu helfen und Zeit für wirklich kritische Aufgaben nutzen zu können. Wie schon Larry Wall sagte, gibt es mehr als einen Weg, um etwas zu erledigen.

Einige Paktebetreuer bevorzugen die Benutzung von hochentwickelten Paketverwaltungswerkzeugen, andere wiederum nicht. Debian ist dies egal. Jedes Werkzeug ist gut was das diese Aufgabe erfüllt. Daher ist dieser Abschnitt nicht dazu gedacht, jemandem vorzuschreiben, welche Werkzeuge er benutzen oder wie er mit seinen Pflichten als Betreuer umgehen soll. Er ist auch nicht dazu gedacht, ein besonderes Werkzeug zu befürworten, um ein anderes auszuschließen.

Die meisten Beschreibungen dieser Pakete entstammen selbst den tatsächlichen Paketbeschreibungen. Weitere Informationen zu den Pakten sind in der Paketbeschreibung selbst zu finden. Sie können außerdem mit dem Befehl apt-cache showPaketname zusätzliche Informationen abrufen.

1.1. Hauptwerkzeuge

Die folgenden Werkzeuge werden größtenteils von jedem Betreuer benötigt.

1.1.1. dpkg-dev

dpkg-dev enthält die Werkzeuge (einschließlich dpkg-source), die benötigt werden, um Debian-Pakete zu entpacken, zu erstellen und hochzuladen. Diese Hilfswerkzeuge enthalten die entsprechend untergeordneten Funktionalitäten, die zum Erstellen und Manipulieren von Paketen benötigt werden; als solche sind diese für jeden Debian-Betreuer erforderlich.

1.1.2. debconf

debconf stellt eine einheitliche Schnittstelle zur Verfügung, um Pakete interaktiv konfigurieren zu können. Es gibt unterschiedliche Bedienoberflächen, d.h. es erlaubt Endanwendern, Pakete mit einer reinen Textoberfläche, einer HTML-Oberfläche oder einer Dialogoberfläche zu konfigurieren. Neue Bedienoberflächen können als Module hinzugefügt werden.

Dokumentation für dieses Paket ist im Paket debconf-doc enthalten.

Viele sind der Ansicht, dieses System sollte für alle Pakete verwendet werden, die eine interaktive Konfiguration erfordern; siehe Konfigurationsverwaltung mit debconf. Derzeit ist debconf nicht in den Debian-Richtlinien vorgeschrieben, was sich aber zukünftig ändern könnte.

1.1.3. fakeroot

fakeroot simuliert Root-Rechte. Dies ermöglicht Ihnen, Pakete zu erstellen, ohne Root zu sein (Pakete möchten üblicherweise Dateien mit Root-Besitzrechten installieren). Falls Sie fakeroot installiert haben, wird dpkg-buildpackage es automatisch benutzen.

1.2. Lint-Werkzeuge für Pakete

Gemäß dem Free On-line Dictionary of Computing (FOLDOC) ist lint ein Unix-Verarbeitungsprogramm für die Sprache C, das gründlichere Code-Prüfungen enthält als übliche C-Compiler. Lint-Werkzeuge für Pakete helfen Paketbetreuern, häufige Probleme und Richtlinienverletzungen in ihren Paketen automatisiert zu finden.

1.2.1. lintian

lintian zerlegt Debian-Pakete und gibt Informationen über Fehler und Richtlinien-Verletzungen aus. Es enthält automatisierte Prüfungen für viele Gesichtspunkte der Debian-Richtlinien, wie auch einige Prüfungen auf häufige Fehler.

Sie sollten sich regelmäßig das neueste lintian aus Unstable installieren und all Ihre Pakete überprüfen. Beachten Sie, dass die Option -i detaillierte Erklärungen liefert, was jeder Fehler oder jede Warnung bedeutet, was deren Grundlage in den Debian-Richtlinien ist und wie das Problem üblicherweise behoben werden kann.

Für weitere Informationen darüber wie und wann Lintian benutzt wird auf Das Paket testen verwiesen.

Sie können außerdem eine Zusammenfassung aller Probleme, die Lintian für Ihre Pakete meldet, unter https://lintian.debian.org/ abfragen. Diese Berichte enthalten die aktuellste Ausgabe von lintian für die ganze Entwicklungsdistribution (Unstable).

1.2.2. lintian-brush

lintian-brush enthält einen Satz an Skripten welche mehr als 80 bekannte Lintian Fehler in Debian Paketen automatisch korrigieren können.

Es kommt mit einem Wrapperskript welches die anderen Skripte aufruft, die Changelog Einträge erstellt (sofern gewünscht) und jede Änderung in die Versionskontrolle einträgt.

1.2.3. piuparts

piuparts ist ein Werkzeug was die .deb Paketinstallation, die Paketaktualisierung und das Entfernen eines Paketes testet.

piuparts testet das .deb Pakete die Installation, eine Aktualisierung und das Entfernen des Paketes korrekt ausgeführen. Dies wird durch die Installation eines Minimal Debians in einem Chroot erreicht indem wiederum die eigentliche Installation, das Upgrade und das Entfernen des Paketes ausgeführt wird und dabei den Zustand des Verzeichnisbaums am Ende der Tests mit dem Zustand vor den Tests vergleicht. piuparts meldet alle Dateien die hinzugefügt, entfernt oder während des Prozesses verändert worden sind.

piuparts ist als Qualitätsicherungswerkzeug für Personen gedacht welche .deb Pakete bauen und diese testen wollen bevor diese ins Debian Archive geladen werden.

1.2.4. debdiff

debdiff (aus dem Paket devscripts, devscripts) vergleicht die Dateilisten und "control"-Dateien zweier Pakete. Es ist ein einfacher Rückfalltest, der Ihnen hilft festzustellen, ob sich die Anzahl der Binärpakete seit dem letzten Upload verändert hat oder ob sich etwas in der "control"-Datei geändert hat. Natürlich werden einige Unterschiede, die ausgegeben werden, in Ordnung sein, aber es kann Ihnen helfen, verschiedene Missgeschicke zu vermeiden.

Sie können es für zusammengehörige Binärpakete ausführen:

debdiff package_1-1_arch.deb package_2-1_arch.deb

Oder auch für zusammengehörige "changes"-Dateien:

debdiff package_1-1_arch.changes package_2-1_arch.changes

Um weitere Informationen zu erhalten, lesen Sie debdiff 1.

1.2.5. diffoscope

diffoscope bietet einen detaillierten Vergleich von Dateien, Archiven und Verzeichnissen.

diffoscope versucht den Unterschieden zwischen Dateien oder Verzeichnissen auf den Grund zu gehen. Es entpackt rekursiv Archive vieler Art und wandelt verschiedene Binärformate in eine besser lesbare Form um, um sie zu vergleichen.

Ursprünglich wurde es entwickelt um .deb Dateien oder zwei changes Dateien zu vergleichen, inzwischen kann es zwei Tarballs, ISO-Images oder PDF Dateien genauso einfach vergleichen und unterstützt eine Vielzahl von Dateitypen.

Die Unterschiede können als Text, als HTML Report oder JSON ausgegeben werden.

1.2.6. duck

duck, der Debian Url ChecKer, verarbeitet mehrere Felder in den Dateien debian/control, debian/upstream, debian/copyright, debian/patches/*, aber auch in Systemd Unit Dateien systemd.unit, es prüft dabei ob URLs, VCS Verlinkungen und E-Mail Adressen-Domainen, die gefunden worden sind, noch gültig sind.

1.2.7. adequate

adequate prüft Pakete die aktuell auf dem System installiert sind und meldet Fehler und Regelverletzungen.

Die folgenden Tests sind aktuell implementiert:

• defekte Symlinks

• fehlende Copyright Datei

• obsolete Konfigurationsdateien

• Python Module die nicht Byte-kompiliert sind

• Programme in /bin und /sbin die Bibliotheken in /usr/lib benötigen

• fehlende Bibliotheken, unbekannte Symbole, nicht passende Größen bei Symbolen

• Lizenzprobleme

• Kollisionen von Programmnamen

• fehlende Alternativen

• fehlende binfmt Interpreter und Detektoren

• fehlende pkg-config Abhängigkeiten

1.2.8. i18nspector

i18nspector ist ein Werkzeug welches Dateien für Übersetzungstemplates (POT), Nachrichtenkataloge (PO) und kompilierte Kataloge (MO) auf gängige Probleme prüft.

1.2.9. cme

cme ist ein Werkzeug aus dem Paket libconfig-model-dpkg-perl und ist ein Editor für die dpkg Quelldateien mit Überprüfung. Prüfen Sie die Paketbeschreibung um zu sehen was das Paket für Sie tun kann.

1.2.10. licensecheck

licensecheck versucht die Lizenz für jede an sie übergebene Datei zu ermitteln, indem nach Textpassagen im Kopf der Dateien gesucht wird die zu verschiedenen Lizenzen gehören.

1.2.11. blhc

blhc ist ein Werkzeug welches in den Logdateien nach dem Bau der Pakete nach fehlenden Hardening Flags sucht.

1.3. Helferskripte für debian/rules

Paketerstellungswerkzeuge erleichtern das Verfassen von debian/rules-Dateien. Lesen Sie Helferskripte, um weitere Informationen darüber zu erhalten, warum dies erwünscht und jenes unerwünscht sein könnte.

1.3.1. debhelper

debhelper ist eine Programmsammlung, die in debian/rules benutzt werden kann, um häufige Aufgaben zu automatisieren, die sich auf das Erstellen binärer Debian-Pakete beziehen. debhelper enthält Programme, um verschiedene Dateien in Ihre Pakete zu installieren, Dateien zu komprimieren, Dateirechte zu korrigieren und Ihr Paket in das Debian-Menüsystem zu integrieren.

Anders als bei anderen Lösungen ist debhelper in mehrere kleine, einfache Befehle aufgeteilt, die auf eine durchgängige Art zusammenarbeiten und dabei eine verglichen mit anderen Tools fein granuläre Kontrolle für debian/rules erlaubt.

Es gibt eine zu große Zahl kleiner Erweiterungspakete für debhelper, die zu verä nderlich sind, um sie hier zu dokumentieren. Sie können die Liste der meisten von Ihnen ansehen, indem Sie apt-cache search ^dh- aufrufen.

Wenn Sie den debhelper Kompatibilitätslevel für ihr Paket wählen, sollten Sie die höchste Kompatibilitätsstufe auswählen, die in der neuesten stabilen Version unterstützt wird. Verwenden Sie eine höhere Kompatibilitätsstufe nur, wenn Sie bestimmte Funktionen benötigen, die von dieser Kompatibilitätsstufe bereitgestellt werden und in früheren Stufen nicht verfügbar sind.

In der Vergangenheit wurde die Kompatibilitätsstufe in debian/compat definiert. Heutzutage ist es jedoch besser, dies nicht mehr zu verwenden, sondern eine versionierte Build-Abhängigkeit wie z.B. debhelper-compat (= 12) zu verwenden.

1.3.2. dh-make

Das Paket dh-make enthält ein Programm namens dh_make, das ein Gerüst von Dateien erstellt, die nötig sind, um Debian-Pakete aus einem Quellcode-Verzeichnisbaum zu erstellen. Wie der Name schon nahelegt, ist dh_make eine Neufassung von debmake, dessen Vorlagendateien dh_*-Programme von debhelper benutzen.

Während die von dh_make generierten "rules"-Dateien im Allgemeinen eine ausreichende Basis für ein funktionierendes Paket bilden, gibt es trotzdem noch weitere grundlegende Arbeiten zu erledigen: Die Hauptarbeit für die Feinabstimmung und das Paket funktional und Richtlinien konform zu machen, liegt immer noch beim Paketbetreuer.

1.3.3. equivs

equivs ist ein weiteres Paket für die Paketerstellung. Es wird oft für den lokalen Gebrauch vorgeschlagen, falls Sie einfach ein Paket erstellen müssen, um Abhängigkeiten zu erfüllen. Es wird manchmal auch benutzt, um Meta-Pakete zu erstellen. Dabei handelt es sich um Pakete, deren einziger Zweck darin besteht, Abhängigkeiten zu anderen Paketen zu generieren.

1.4. Werkzeuge zum Paketbau

Die folgenden Pakete helfen beim Prozess der Paketerstellung und führen im Allgemeinen dpkg-buildpackage aus, um unterstützende Aufgaben zu behandeln.

1.4.1. git-buildpackage

git-buildpackage stellt die Fähigkeit bereit, Debian-Quellpakete in ein Git-Repository aufzunehmen oder zu importieren, ein Debian-Paket aus dem Git-Repository zu bauen und bei der Integration von Änderungen der Originalautoren in das Repository zu helfen.

Diese Hilfswerkzeuge bieten eine Infrastruktur, um Debian-Betreuern den Gebrauch von Git zu erleichtern. Dies ermöglicht es, getrennte Git-Zweige von Paketen für die Distributionen Stable, Unstable und möglicherweise Experimental vor zuhalten, zusammen mit den anderen Vorteilen eines Versionsverwaltungssystems.

1.4.2. debootstrap

Das Paket und Skript debootstrap ermöglicht Ihnen das Urladen eines Debian-Basissystems in irgendeinen Teil Ihres Dateisystems. Mit Basissystem ist hier das Minimum an installierten Paketen gemeint, die nötig sind, um den Rest des Systems zu betreiben und zu installieren.

Ein solches System zu haben, kann in vielerlei Hinsicht nützlich sein. Sie können zum Beispiel mit chroot in das System gehen und Ihre Build-Abhängigkeiten testen. Oder Sie können testen, wie sich Ihr Paket verhält, wenn es in ein nacktes Basissystem installiert wird. Chroot-Builder benutzen dieses Paket; siehe weiter unten.

1.4.3. pbuilder

pbuilder erstellt ein Chroot-System und baut ein Paket innerhalb der Chroot-Umgebung. Es ist sehr nützlich, um die Build-Abhängigkeiten des Pakets zu überprüfen und sicherzustellen, dass keine unnötigen oder falschen Build-Abhängigkeiten in dem resultierenden Paket existieren.

Ein verwandtes Paket ist cowbuilder, das den Bauprozess mittels eines COW-Dateisystems auf jedem Standard-Linux-Dateisystem beschleunigt.

1.4.4. sbuild

sbuild ist ein weiterer automatisierter Builder. Er kann auch Chroot-Umgebungen benutzen. Er kann eigenständig benutzt werden oder als Teil einer verteilten Build-Umgebung über ein Netzwerk. Als letzteres ist er Teil des Systems, das Portierer benutzen, um Binärpakete für all die verfügbaren Architekturen zu erstellen. Weitere Informationen finden Sie in wanna-build und unter https://buildd.debian.org/ können Sie das System in Aktion sehen.

1.5. Programme zum Hochladen von Paketen

Die folgenden Pakete helfen, den Prozess, Pakete in das offizielle Archiv hochzuladen, zu automatisieren oder zu vereinfachen.

1.5.1. dupload

Das Paket dupload enthält ein gleichnamiges Skript mit dem automatisierte Dinge ausgeführt werden können wie ein Paket ins Debian Archiv hochzuladen, dieses Hochladen zu monitoren und optional eine E-Mail nach einen Paket Upload zu verschicken. Es unterstützt verschiedene Arten von Hooks um die eigene Funktionalität zu erweitern, es kann aber auch so konfiguriert werden, dass es neue Uploadziele oder Methoden unterstützt. Standardmäßig beinhaltet es schon verschiedene Hooks die Tests ausführen und beinhaltet ebenso eine Konfiguration die alle Uploadziele innerhalb Debians unterstützt.

1.5.2. dput

Mit dem Paket und Skript dput lässt sich das gleiche erreichen wie mit dupload, aber auf eine andere Art. Standardmäßig wird die Ausführung von dinstall im Leerlaufmodus (dry-run) nach dem Hochladen unterstützt.

1.5.3. dcut

Das Skript dcut (Teil des Pakets dput, dput) hilft beim Entfernen von Dateien aus dem FTP-Upload-Verzeichnis.

1.6. Automatisierung der Verwaltungsaufgaben

Die folgenden Werkzeuge helfen, verschiedene Verwaltungsaufgaben vom Hinzufügen von Änderungsprotokolleinträgen oder Signaturzeilen über das Nachschlagen von Fehlern in Emacs bis zum Gebrauch vom neuesten und offiziellen config.sub zu automatisieren.

1.6.1. devscripts

devscripts ist ein Paket mit Wrappern und Werkzeugen, die für die Pflege Ihrer Debian-Pakete sehr hilfreich sind. Beispielskripte sind debchange (oder sein Alias dch), das Ihre debian/changelog-Datei über die Befehlszeile bearbeitet, bis hin zu debuild was ein ein Wrapperskript um dpkg-buildpackage herum ist. Das Dienstprogramm bts ist auch sehr hilfreich, um z.B. den Status von Fehlerberichten von der Kommandozeile aus zu aktualisieren. uscan kann verwendet werden, um nach neuen Upstream-Versionen Ihrer Pakete zu suchen (Siehe hierzu https://wiki.debian.org/debian/watch für mehr Informationen). suspicious-source gibt eine Liste von Dateien aus, die keine allgemein bekannten Quelldateien sind.

Eine vollständige Liste der verfügbaren Skripte finden Sie auf der Handbuchseite devscripts 1.

1.6.2. reportbug

reportbug ist ein Werkzeug welches geschaffen wurde um das Melden von Fehlern in Debian und abgeleiteten Derivaten relativ problemlos zu gestalten. Zu den Eigenschaften gehören:

• Integration mit mutt und mh/nmh E-Mail Readern.

• Zugriff auf offene Fehlerberichte, um leichter feststellen zu können, ob bereits Probleme gemeldet wurden.

• Automatisches prüfen nach neuen Versionen von Paketen.

reportbug ist für die Verwendung auf Systemen mit einem installierten MTA (Mail Transport Agent) vorgesehen. Sie können die Konfigurationsdatei jedoch bearbeiten und Berichte über einen beliebigen verfügbaren Mailserver senden.

Dieses Paket enthält auch das Skript querybts um das Debian Bug Tracking System durchsuchen zu können.

1.6.3. autotools-dev

autotools-dev enthält optimale Vorgehensweisen für Maintainer, die Pakete betreuen, in denen autoconf und/oder automake zum Einsatz kommt. Außerdem enthält es anerkannte config.sub und config.guess Dateien, von denen bekannt ist, dass sie auf allen Debian-Portierungen funktionieren.

1.6.4. dpkg-repack

dpkg-repack erstellt eine Debian-Paketdatei aus einem Paket, das bereits installiert wurde. Falls irgendwelche Änderungen vorgenommen wurden, während das Paket entpackt war (es wurden z.B. Dateien in /etc verändert), wird das neue Paket die Änderungen erben.

Dieses Hilfswerkzeug kann das Kopieren von Paketen von einem Rechner zu einem anderen, das Neuerstellen von Paketen, die auf Ihrem System installiert wurden, aber nirgendwo mehr verfügbar sind, oder das Sichern des derzeitigen Paketstatus vor dem Upgrade vereinfachen.

1.6.5. alien

alien konvertiert Binärpakete zwischen verschiedenen Paketformaten, einschließlich Debian, RPM (RedHat), LSB (Linux Standard Base), Solaris und Slackware.

1.6.6. dpkg-dev-el

dpkg-dev-el ist ein Emacs-Lisp-Paket, das Unterstützung beim Bearbeiten von Dateien im debian-Verzeichnis Ihres Pakets bietet. Es gibt dort zum Beispiel praktische Funktionen, um die aktuellen Fehler eines Programms aufzulisten und um den aktuellen Eintrag in einer debian/changelog-Datei abzuschließen.

1.6.7. dpkg-depcheck

dpkg-depcheck (aus dem Paket devscripts, devscripts) führt einen Befehl unter strace aus, um festzustellen, welche Pakete vom angegebenen Befehl benutzt werden.

Für Debian-Pakete ist dies nützlich, wenn Sie eine Build-Depends-Zeile für Ihr neues Paket erstellen müssen: Wenn Sie den Build-Prozess durch dpkg-depcheck auszuführen, dann wird eine gute erste Übersicht über die Build-Abhängigkeiten ausgegeben werden. Zum Beispiel so aufgerufen:

dpkg-depcheck -b debian/rules build

dpkg-depcheck kann außerdem benutzt werden, um Laufzeitabhängigkeiten zu prüfen, insbesondere, wenn Ihr Paket exec 2 benutzt, um andere Programme auszuführen.

Weitere Informationen finden Sie unter dpkg-depcheck 1.

1.6.8. debputy

Das Programm debputy ist seit 2024 neu. Während der Hauptzweck des Programms darin besteht ein neues Build-Paradigma für Debian-Pakete bereitzustellen, enthält debputy einige Befehle, die mit jedem bestehenden Debian-Paket verwendet werden können, um die Korrektheit der meisten Dateien in debian/* zu prüfen und in vielen Fällen auch automatisch herstellen zu können.

Um die Korrektheit von Dateien in debian/* zu überprüfen, kann dieser Befehl verwendet werden:

debputy lint --spellcheck

Die Dateien debian/control und debian/tests/control können so formatiert werden:

debputy reformat --style black

Die Verwendung des Befehls reformat ersetzt die Verwendung von wrap-and-sort -ast.

Das Werkzeug debputy enthält ebenfalls einen Sprach-Server, der, wenn in einen Editor integriert, Echtzeit-Rückmeldung über die Korrektheit von Dateien in debian/* während der Bearbeitung gibt.

Um weitere Informationen zu erhalten, lesen Sie debputy 1.

1.7. Portierungswerkzeuge

Die folgenden Werkzeuge sind hilfreich für Portierer und zur Kompilierung für andere Plattformen.

1.7.1. dpkg-cross

dpkg-cross ist ein Werkzeug, um Bibliotheken und Header zum Kompilieren auf anderen Plattformen auf eine Art zu installieren, die dpkg ähnlich ist. Weiterhin verbessert es die Funktionalität von dpkg-buildpackage und dpkg-shlibdeps, um das Kompilieren von Paketen für andere Plattformen (cross-compiling) zu unterstützen.

1.8. Dokumentation und Information

Die folgenden Pakete stellen Informationen für Betreuer zur Verfügung oder helfen bei der Erstellung von Dokumentation.

1.8.1. debian-policy

Das Paket debian-policy enthält das Debian Richtlinienhandbuch und zugehörige Dokumente, diese sind:

• Debian Richtlinienhandbuch

• Filesystem Hierarchy Standard (FHS)

• Regeln für Menüs in Debian

• Spezifische Regeln für Perl in Debian

• Spezifikationen des Debian Konfigurationsmanagment

• Spezifikation für eine maschinell lesbare Datei debian/copyright

• Autopkgtest - Automatisches Testen von Paketen im installierten Zustand

• Maßgebliche Liste der Namen von virtueller Paketen

• Checkliste mit Regeln für das Aktualisieren Ihrer Paketen

Das Debian-Richtlinienhandbuch enthält die Richtlinien zu Paketen und Einzelheiten zum Mechanismus des Paketierens. Es deckt alles ab, von den erforderlichen "gcc"-Optionen bis hin zur Funktionsweise der Betreuerskripte ("postinst" usw.), Sektionen für Paketen und Prioritäten usw.

Auch sehr nützlich ist die Datei /usr/share/doc/debian-policy/upgrading-checklist.txt.gz, diese listet die Änderungen zwischen den verschieden Versionen der Debian Richtlinie auf.

1.8.2. doc-debian

doc-debian enthält ein große Menge an Debian spezifischer Dokumentation:

• Debian Linux Manifesto

• Verfassung des Debian Projektes

• Debian Gesellschaftervertrag

• Debian Free Software Guidelines

• Dokumentation des Debian Bug Tracking System

• Einführung in die Debian Mailinglisten

1.8.3. developers-reference

Das Paket developers-reference enthält das Dokument, welches Sie gerade lesen, die Debian Developer's Reference ist eine Reihe von Richtlinien und Best Practices, die von und für die Gemeinschaft der Debian-Entwickler erstellt wurden.

1.8.4. maint-guide

Das Paket maint-guide enthält den "Debian-Leitfaden für Neue Paketbetreuer".

Dieses Dokument versucht den normalen Debian-Benutzern und potenziellen Entwicklern den Aufbau eines Debian-Pakets zu beschreiben. Es verwendet bewusst eine nicht-technische Sprache und hat ein Reihe an Arbeitsbeispielen.

1.8.5. debmake-doc

Das Paket debmake-doc enthält den "Leitfaden für Debian-Betreuer".

Dieses Dokument ist neuer als der "Debian-Leitfaden für Neue Paketbetreuer" und zielt darauf ab, es zu ersetzen. Der "Leitfaden für Debian-Betreuer" richtet sich an Leute, die Paketierung für Debian erlernen wollen, und deckt eine breite Spanne von Themen und Werkzeugen ab, zusammen mit vielen Beispielen zu verschiedenen Paketierungsproblemen.

1.8.6. packaging-tutorial

Dieses Tutorial ist eine Einführung in die Paketierung von Debian Paketen. Hier erfahren angehende Entwickler, wie sie vorhandene Pakete ändern, eigene Pakete erstellen können und mit der Debian-Gemeinschaft interagieren können.

Zusätzlich zum Haupt-Tutorial enthält es drei praktische Beispiele wie zum ändern des grep Paketes, zum Paketieren des gnujump Spiels und einer Java Bibliothek.

1.8.7. how-can-i-help

how-can-i-help zeigt Möglichkeiten für Beiträge zu Debian auf. how-can-i-help hängt sich in APT, um Möglichkeiten für Beiträge zu Debian (verwaiste Pakete, Fehler mit dem Tag 'newcomer') für lokal installierte Pakete nach jedem APT Aufruf aufzulisten. Es kann auch direkt aufgerufen werden und listet dann alle Beitragsmöglichkeiten auf (nicht nur die neuen).

1.8.8. docbook-xml

docbook-xml stellt die DocBook-XML-Dokumenttypdefinitionen (DTD) bereit, die häufig für Debian-Dokumentation benutzt werden (genauso wie die ältere Debiandoc-SGML-DTD).

Das Paket docbook-xsl stellt XSL-Dateien zum Erstellen und Gestalten der Datenquelle in verschiedenen Ausgabeformaten bereit. Sie benötigen einen XSLT-Prozessor wie xsltproc, um die XSL-Stylesheets zu verwenden. Dokumentation für die Stylesheets finden Sie in den verschiedenen docbook-xsl-doc-*-Paketen.

Um ein PDF aus FO zu erstellen, benötigen Sie einen FO-Prozessor wie xmlroff oder fop. Ein weiteres Werkzeug, um PDF aus DocBook-XML zu generieren, ist dblatex.

1.8.9. debiandoc-sgml

debiandoc-sgml stellt die DebianDoc-SGML-Dokumenttypdefinitionen (DTD) bereit, die normalerweise für Debian-Dokumentation benutzt worden ist, aber nun als veraltet gilt (stattdessen sollte docbook-xml oder python3-sphinx benutzt werden).

1.8.10. debian-keyring

Dieses Paket enthält die öffentlichen OpenPGP-Schlüssel der Debian-Entwickler und Paketbetreuer. Siehe Verwalten Ihres öffentlichen Schlüssels und die Paketdokumentation für weitere Informationen.

1.8.11. debian-el

debian-el stellt einen Emacs-Modus bereit, um Debian-Binärpakete anzusehen. Dies ermöglicht Ihnen, ein Paket zu untersuchen, ohne es entpacken zu müssen.