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

You should set the subject of the bug to `ITP:` foo `--` short description, substituting the name of the new package for foo. The severity of the bug report must be set to `wishlist`. Please send a copy to `debian-devel@lists.debian.org` by using the X-Debbugs-CC header (don't use CC:, because that way the message's subject won't indicate the bug number). If you are packaging so many new packages (>10) that notifying the mailing list in separate messages is too disruptive, send a summary after filing the bugs to the debian-devel list instead. This will inform the other developers about upcoming packages and will allow a review of your description and package name.

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.

There are tools to help you create entries and finalize the `changelog` for release — see devscripts (command `dch`), git-buildpackage (command `gbp dch`) and 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 -v` Paket-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.

- With the package installed, run `adequate <package name>` to test its installed state for policy violations. Ideally, you should automate this step using `autopkgtest` (see adequate).

- 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 `trixie` oder `bookworm`. Ü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 benötigt eine korrekte Versionsnummer (z.B. `...+deb13u1`/`...~deb13u1` für `trixie` oder `+deb12u1`/`~deb12u1` für `bookworm`) und Sie sollten in der Lage sein zu erklären welche Tests vorgenommen wurden. Im Debian Richtlinienhandbuch sind Informationen zu der Versionsnummer unter: 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. `trixie`.

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.

If possible, the version of a package that is uploaded should be a source-only changes file. These are typically named `*_source.changes`, and reference the source package, but no binary `.deb` or `.udeb` packages. All of the corresponding architecture-dependent and architecture-independent binary packages, for all architectures, will be built automatically by the build daemons in a controlled and predictable environment (see wanna-build for more details).

For many source-only uploads you can use tag2upload instead, which means that you only need to push a signed Git tag to Salsa, instead of generating and signing `.dsc` and `.changes` files yourself. See https://wiki.debian.org/tag2upload.

There are several situations where a source-only upload is not possible.

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.

### 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

It is sometimes useful to upload a package immediately, but to want this package to arrive in the archive only a few days later. For example, when preparing a Non-Maintainer Uploads (NMUs), you might want to give the maintainer a few days to react, while at the same time having the certainty that your upload will eventually take effect if the maintainer does not. A one-shot approach of (i) file bug with a patch (or Merge Request) and (ii) at once upload to DELAYED, is much more efficient than having to wait for days between the two steps.

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.

Sometimes you'll need to remove a previously uploaded package from the DELAYED queue (e.g. because the package maintainer has asked you so). dcut(1) has examples of how to do so.

### 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. New upstream versions

To update a package for a new upstream release:

1. Read the upstream changelog, NEWS, and whatever other documentation they may have released with the new version.

2. If possible, inspect the full diff between the old and new upstream sources, potentially filtering out uninteresting parts using filterdiff (e.g. `filterdiff -x '*.po'`). If it's too big to review thoroughly, you can use `diffstat` to get a feel for the scope and nature of the changes (and thus where new bugs may appear), and to keep an eye for anything suspicious (e.g. unexpected use of network or the apperance of dubious binary blobs).

3. Port the old Debian packaging to the new version. This basically involves incrementing the `debian/changelog` and merging `debian/patches` from the old package to the new one.

4. Check to see if any bugs have been fixed that are currently open in the BTS. If they have been, close them in the `debian/changelog`.

5. If the patch/merge did not apply cleanly, figure out why. A patch may fail to apply if it's already been applied in the new upstream release, or if the upstream files the patch applies to have been substantially modified (or deleted).

6. If any changes were made to the build system (you'd know from steps 1 and 2), update the `debian/rules` and `debian/control` build dependencies if necessary.

7. Build the new package in an isolated environment, e.g. using `sbuild` or `pbuilder`. This ensures that all required build dependencies are listed in `debian/control` and eliminates the possibility of interference of any third party packages in your system.

8. Verify that the new package builds correctly and if so carry out the checks in _sanitycheck.

## 5.9. 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.9.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.9.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.9.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. If the bug is related to the packaging, you just fix it. If you are not able to fix it yourself, then tag the bug as `help`. You can also ask for help on `debian-devel@lists.debian.org` or `debian-qa@lists.debian.org`. See Abstimmung mit Originalautoren if it's an upstream problem. If you have the required skills you can prepare a patch that fixes the bug and send it to the author at the same time. Make sure to send the patch to the BTS and to tag the bug as `patch`.

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.9.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.9.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.9.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.9.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.9.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.9.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. `trixie-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, `+deb` X `u1` anzuhängen (wobei X die Major-Release-Nummer ist), z.B. `1:2.4.3-4+deb13u1` 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.9.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.10. Subscribing to package updates

As a maintainer of a package, you get email notifications for various kinds of events (uploads, BTS messages etc). You can subscribe to receive such notifications also for packages you are not a maintainer of (or packages you maintain collaboratively), by mailing `control@tracker.debian.org` with `subscribe <pkgname>` either in the subject or the body of the email (see https://qa.pages.debian.net/distro-tracker/usage/messages.html#email-messages for details).

## 5.11. 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.11.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.11.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.

Further information relating to these and other package removal related topics may be found at https://wiki.debian.org/ftpmaster_Removalsand 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.11.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.11.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.11.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.11.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.11.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.12. 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 8 weitere Builds hinausläuft.

### 5.12.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. When you can't support your package on a particular architecture, you shouldn't use the Architecture field to reflect that (it's also a pain to maintain correctly). If the package fails to build from source, you can just let it be and interested people can take a look at the build logs. If the package would actually build, the trick is to add a `Build-Depends` on `unsupported-architecture [the-not-supported-arch]`. The buildds will not build the package as the build dependencies are not fulfilled on that arch. To prevent building on 32-bits architectures, the `architecture-is-64-bit` build dependency can be used, as `architecture-is-little-endian` can be used to prevent building on big endian systems.

### 5.12.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.12.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 `b` Zahl 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.12.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.12.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.12.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.12.3.2. Werkzeuge der Portierer

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

#### 5.12.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.12.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.12.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.13. 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.13.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.) NMUs sollten nicht verwendet werden um Änderungen zu machen, die wahrscheinlich nicht einvernehmlich sind.

- Die folgenden Änderungen werden beispielsweise generell als akzeptable angesehen, außer es gibt gute Gründe den Praktiken für ein bestimmtes Paket nicht zu folgen: Verwendung des letzten veröffentlichten debhelper Kompatibilitätslevels; Verwendung von dh; Verwendung von Format 3.0 (quilt); Verwendung von lintian-brush.

- 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: fünfzehn 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.

After you upload an NMU, you are responsible for the possible problems that you might have introduced. You must keep an eye on the package (Subscribing to package updates is a good way to achieve this).

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.13.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 `+nmu` X 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 `+deb` X `u` Y benutzt werden, wobei X die Major-Release-Nummer und Y eine fortlaufende, bei `1` beginnende Nummer ist. Während zum Beispiel `trixie` (Debian 13) 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+deb13u1`, während ein Sicherheits-NMU für `forky` die Version `1.5-3+deb14u1` erhalten würde.

### 5.13.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.13.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`+really` VORHERIGE 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.

Beachten Sie, der einfachste Weg, um sowohl zu prüfen ob Ihr Paket einen NMU erhalten hat als auch gleichzeitig automatisch die Änderungen herunterzuladen und in ein durch git-buildpackage verwaltetes Git-Repository einzuchecken, ist folgenden Befehl auszuführen `gbp import-dsc --verbose --pristine-tar apt:<package>/sid`. Der Beispielbefehl geht davon aus, dass Sie auf dem `debian/latest`-Branch arbeiten und den nächsten Upload für Debian Unstable vorbereiten. Ebenfalls wird angenommen, dass Ihr `apt` die `deb-src`-Zeile für Debian Unstable aktiviert hat.

### 5.13.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.13.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.13.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.14. 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.14.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.14.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.15. 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>

- The co-maintainers should subscribe themselves to the appropriate source package (see Subscribing to package updates).

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.16. Die Distribution Testing

### 5.16.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.16.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.16.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.16.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.16.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.16.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.16.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.16.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 `+deb` X `uY` 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+deb13u1`.

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. `forky`) 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.16.4. Häufig gestellte Fragen

#### 5.16.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.16.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.17. Das Archive von Stable Backports

### 5.17.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.17.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.17.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.17.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.17.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.17.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.17.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.