Inhaltsverzeichnis
Dieses Kapitel enthält Informationen, die sich auf das Erstellen, Hochladen Verwalten und Portieren von Paketen beziehen.
Falls Sie eine 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.
Assuming no one else is already working on your prospective package, you
must then submit a bug report (Abschnitt 7.1, „Fehler berichten“) against the
pseudo-package wnpp
describing your
plan to create a new package, including, but not limiting yourself to, the
description of the package (so that others can review it), the license of
the prospective package, and the current URL where it can be downloaded
from.
Sie sollten den Betreff des Fehlers auf ITP:
setzen, wobei Sie
Paketname
-- kurze
Beschreibung
Paketname
durch den Namen Ihres Pakets
ersetzen. Der Schweregrad des Fehlerberichts sollte auf
wishlist
gesetzt werden. Bitte senden Sie mit der
Kopfzeile X-Debbugs-CC eine Kopie an <debian-devel@lists.debian.org>
(benutzen Sie
nicht CC:, da in diesem Fall der Betreff der Nachricht die Fehlernummer
nicht angibt). Falls Sie so viele (mehr als zehn) neue Pakete paketieren,
dass die Benachrichtigung auf der Liste als störend empfunden würde, senden
Sie stattdessen nach dem Einreichen des Fehlers eine Zusammenfassung an die
Liste »debian-devel«. Dies wird andere Entwickler über die bevorstehenden
Pakete informieren und eine Überprüfung Ihrer Beschreibung und Ihres
Paketnamens ermöglichen.
Bitte fügen Sie im Änderungsprotokoll des neuen Pakets den Eintrag
Closes: #
hinzu, um den
Fehlerbericht automatisch zu schließen, sobald das neue Paket im Archiv
installiert wird (siehe Abschnitt 5.8.4, „Wann Fehler durch neue Uploads geschlossen werden“).
nnnnn
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, im Fall dass Sie bereits erneut hochladen.
Wenn sicherheitskritische Fehler geschlossen werden, fügen Sie die
CVE-Nummern sowie Closes:
#
bei. Dies ist nützlich zur
Verfolgung von Schwachstellen durch das Sicherheits-Team. Falls etwas
hochgeladen wird, bevor die Warnungs-ID 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.
nnnnn
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 eine
Beschreibungszeile 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 von unstable
zehren (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.
Von Ihnen vorgenommene Änderungen müssen in
debian/changelog
aufgezeichnet werden. 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/
oder
Paket
/changelog.Debian.gz/usr/share/doc/
für native Pakete installiert.
Paket
/changelog.gz
Die Datei debian/changelog
entspricht einer bestimmten
Struktur mit einer Anzahl unterschiedlicher Felder. Ein bedeutendes Feld,
die distribution
, wird in Abschnitt 5.5, „Eine Distribution herausgreifen“
beschrieben. Weitere Informationen über die Struktur dieser Datei können im
Abschnitt debian/changelog
der Debian-Richtlinien
gefunden werden.
Wenn das Paket im Archiv installiert ist, können Einträge im Änderungsprotokoll benutzt werden, um Debian-Fehler automatisch zu schließen. Siehe Abschnitt 5.8.4, „Wann Fehler durch neue Uploads geschlossen werden“.
Es ist üblich, dass der Änderungsprotokolleintrag eines Pakets, der eine neue Originalversion der Software enthält, wie folgt aussieht:
* New upstream release.
Es gibt Werkzeuge, die Ihnen helfen Einträge zu erstellen und das
changelog
zur Veröffentlichung fertigzustellen – siehe
Abschnitt A.6.1, „devscripts
“ und Abschnitt A.6.5, „dpkg-dev-el
“.
Siehe auch Abschnitt 6.3, „Optimale Vorgehensweisen für debian/changelog
“.
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):
Installieren Sie das Paket und stellen Sie sicher, dass die Software funktioniert oder führen Sie ein Upgrade von der älteren Version auf Ihre neue Version durch, falls bereits ein Debian-Paket existiert.
Führen Sie für das Paket lintian aus. Sie können
lintian wie folgt ausführen: lintian -v
. 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.
Paket-Version
.changes
Normalerweise sollte ein Paket nicht hochgeladen
werden, wenn es lintian-Fehler verursacht (sie beginnen
mit E
).
Weitere Informationen über lintian finden Sie unter Abschnitt A.2.1, „lintian
“.
Führen Sie wahlweise debdiff (siehe Abschnitt A.2.2, „debdiff“) aus, um Änderungen von einer älteren Version zu analysieren, falls es solche gibt.
Downgraden Sie das Paket auf die vorherige Version (falls es eine gibt) –
dies testet die Skripte postrm
und
prerm
.
Entfernen Sie das Paket und installieren Sie es erneut.
Kopieren Sie das Quellpaket in ein anderes Verzeichnis und versuchen Sie es
zu entpacken und neu zu erstellen. Dies testet, ob das Paket auf bestehenden
Dateien von außen beruht oder ob es auf Benutzerrechten beruht, die in den
Dateien konserviert wurden, die innerhalb der
.diff.gz
-Datei mitgeliefert wurden.
Es gibt zwei Typen von Debian-Quellpaketen:
die sogenannten native
-Pakete, bei denen es keine
Unterschiede zwischen den Originalquellen und den auf Debian angewandten
Patchs gibt
die (häufigeren) Pakete, bei denen die Original-Quellcode-Tarball-Datei 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
der Ursprungsquelle entspricht, könnte 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 der
Notwendigkeit sie 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. Diese Verhalten könnte
durch die Benutzung von -sa
geändert werden, um es immer
einzubeziehen oder -sd
, um es immer wegzulassen.
Falls im Upload keine Originalquelle enthalten ist, wird die
Original-Tar-Quelldatei von dpkg-source benutzt, wenn die
.dsc
-Datei erzeugt wird und die Diff-Datei, die
hochgeladen werden soll, muss 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.
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.
Es gibt mehrere mögliche Werte für dieses Feld: stable
,
unstable
, testing-proposed-updates
und
experimental
. Normalerweise werden Pakete nach
unstable
hochgeladen.
Tatsächlich gibt es andere mögliche Distributionen:
Codename
-security
, aber lesen
Sie Abschnitt 5.8.5, „Handhabung von sicherheitsrelevanten Fehlern“, um weitere Informationen darüber zu
erhalten.
Es ist nicht möglich ein Paket gleichzeitig in mehrere Distributionen hochzuladen.
Hochladen nach stable
bedeutet, dass das Paket in die
Warteschlange proposed-updates-new
übertragen wird, damit
es von den Veröffentlichungsverwaltern von Stable überprüft wird. Falls es
zugelassen wird, wird es im Verzeichnis
stable-proposed-updates
des Debian-Archivs
installiert. Von dort wird es zum nächsten Veröffentlichungszeitpunkt in
stable
eingefügt.
Um sicherzustellen, dass Ihr Upload akzeptiert wird, sollten Sie die
Änderungen mit dem Stable-Release-Team besprechen bevor Sie es
hochladen. Dazu reichen Sie mittels reportbug einen
Fehlerbericht gegen das Pseudo-Paket release.debian.org
ein, einschließlich dem
Patch, das Sie auf die derzeit in stable
enthaltene
Paketversion anwenden möchten. Schreiben sie beim Upload in die Distribution
stable
stets detaillierte und ausführliche
Änderungsprotokolleinträge.
Sie sollten beim Hochladen nach stable
besonders
vorsichtig sein. Grundsätzlich sollte ein Paket nur nach
stable
hochgeladen werden, wenn folgendes geschieht:
ein wirklich kritisches Funktionalitätsproblem
Das Paket ist wird uninstallierbar.
Einer veröffentlichten Architektur fehlt das Paket.
Früher wurden Uploads nach stable
benutzt, um auch
Sicherheitsprobleme anzugehen. Diese Praxis ist jedoch missbilligt, da
Uploads für Debian-Sicherheitswarnungen automatisch in das entsprechende
Archiv proposed-updates
kopiert werden, wenn die
Warnung veröffentlicht wird. Weitere detailliertere Informationen über die
Handhabung von Sicherheitsproblemem finden Sie unter Abschnitt 5.8.5, „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 nichtsdestotrotz bereit, Ihre Fehlerbehebung
bei einem regulären Upload nach stable
einzufügen.
Es wird abgeraten, etwas anderes unwichtiges im Paket zu ändern, da sogar einfache Fehlerbehebungen zu weiteren Fehlern führen können.
Pakete, die nach stable
hochgeladen werden, müssen auf
Systemen compiliert werden, auf denen stable
läuft, so
dass sich ihre Abhängigkeiten auf die Bibliotheken (und anderen Pakete)
beschränken, die auf stable
verfügbar sind. Ein Paket,
das zum Beispiel nach stable
hochgeladen wurde, das von
einem Bibliothekspaket abhängt, das nur in unstable
existiert, wird zurückgewiesen. Von Änderungen an Abhängigkeiten von anderen
Paketen (durch Murksen mit Provides
- oder
shlibs
-Dateien), die diese anderen Pakete
möglicherweise uninstallierbar machen, wird dringend abgeraten.
Uploads nach oldstable
-Distributionen sind möglich,
solange sie nicht archiviert sind. Es gelten die gleichen Regekn, wie für
stable
.
Bitte lesen Sie die Informationen im Bereich Testing, um weitere Einzelheiten zu erfahren.
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, benötigen Sie einen
signierten Schlüssel im Debian-Entwickler-Schlüsselbund (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, wenn Sie Pakete hochladen. Diese praktischen Programme helfen den Prozess des Hochladens von Paketen nach Debian zu automatisieren.
Um Pakete zu entfernen, sehen Sie sich bitte ftp://ftp.upload.debian.org/pub/UploadQueue/README und das Debian-Paket dcut an.
Manchmal ist es nützlich ein Paket sofort hochzuladen, aber zu wünschen, dass dieses Paket das Archiv erst ein paar Tage später erreicht. Sie könnten, wenn Sie beispielsweise einen Non-Maintainer Upload vorbereiten, dem Betreuer ein paar Tage Zeit geben wollen, damit er reagieren kann.
Ein Upload des Pakets in das Verzögerungsverzeichnis, wird es in der deferred uploads
queue halten. Wenn die angegebene Wartezeit vorüber ist, wird das
Paket zur Verarbeitung in das reguläre Eingangsverzeichnis verschoben. Dies
wird durch automatisches Hochladen nach ftp.upload.debian.org
in das Upload-Verzeichnis
DELAYED/
(X
-dayX
zwischen 0 und 15). 0-day wird mehrmals
täglich nach ftp.upload.debian.org
hochgeladen.
Mit Dput können Sie den Parameter --delayed
benutzen, um das Paket in
eine der Warteschlangen einzureihen.
VERZÖGERUNG
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 Abschnitt 5.8.5, „Handhabung von sicherheitsrelevanten Fehlern“.
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ögerten
Uploads.
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
gehandhabt. Im Besonderen werden Aktualisierungen zu existierenden Paketen
in der Distribution unstable
automatisch eingepfelgt. 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 Bereich das Paket eingefügt wird. Falls es dort einen Unterschied 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.
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 tatsächlich 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
wünschen.
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 Abschnitt 4.6.1, „Abschnitte“ erläutert werden. Falls der Bereich »main« ist,
sollte er weggelassen werden. Die Liste der erlaubten Unterbereiche kann
unter https://www.debian.org/doc/debian-policy/ch-archive.html#s-subsections
gefunden werden.
Jeder Entwickler muss in der Lage sein, mit der Debian-Fehlerdatenbank zu arbeiten. Dies umfasst das Wissen, wie Fehlerberichte richtig eingeordnet werden (siehe Abschnitt 7.1, „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 gehandhabt. All die 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.
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/
.
Ihre_Anmeldung
@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,
können Sie in die lokalen Dateien /usr/share/doc/debian/bug-*
sehen.
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 umreißt:
# Anfrage wöchentlicher Berichte über Fehler in eigenen Paketen
0 17 * * fri echo "index maint address
" | mail request@bugs.debian.org
Ersetzen Sie Adresse
durch Ihre offizielle
Debian-Betreueradresse.
Wenn Sie auf Fehler antworten, stellen Sie sicher, dass jegliche Diskussion,
die Sie über Fehler führen, sowohl an den Originalabsender, als auch an den
Fehler selbst geschickt wird
(z.B. <
). Falls Sie
eine neue E-Mail schreiben und sich nicht an die Absender-E-Mail-Adresse
erinnern, können Sie die E-Mail-Adresse
123
@bugs.debian.org><
benutzen, um den Absender zu kontaktieren und Ihre
E-Mail innerhalb des Fehlerprotokolls aufzuzeichnen (das bedeuted, dass Sie
keine Kopie dieser E-Mail an
123
-submitter@bugs.debian.org><
senden müssen.
123
@bugs.debian.org>
Falls Sie einen Fehlerbericht erhalten, der FTBFS erwähnt, so bedeutet dies »Fails to build from source« (Kann nicht aus der Quelle erstellt werden). Portierer benutzen diese Abkürzung öfters.
Sobald Sie einen Fehlerbericht erledigt haben (z.B. den Fehler beheben),
markieren Sie ihn als done
(dies schließt ihn), indem Sie
eine Erklärung an
<
senden. Falls
Sie einen Fehler durch Ändern und Hochladen des Pakets schließen, können Sie
das Schließen von Fehlern, wie in Abschnitt 5.8.4, „Wann Fehler durch neue Uploads geschlossen werden“
beschrieben, automatisieren.
123
-done@bugs.debian.org>
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.
Als Paketbetreuer werden Sie öfters 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 Richtlinien für die Verwaltung Ihrer eigenen Fehler, die auf der gesammelten Erfahrung der Debian-Entwickler basieren.
Fehler für Probleme einreichen, die Sie in anderen Paketen finden, ist eine der bürgerlichen Pflichten des Betreuerdaseins. Einzelheiten finden Sie unter Abschnitt 7.1, „Fehler berichten“. Es ist jedoch wichtiger die Fehler in Ihren eigenen Paketen zu behandeln.
Hier ist eine kurze Liste der Schritte, denen Sie zu Handhabung eines Fehlerberichts folgen können:
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 nur und stellen Sie informationen bereits, 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 aussgagekräftige Fehlermeldung auszugeben. Dies ist ein Thema, das Sie mit dem Originalautor angehen sollten.
Falls der Absender des Fehler nicht mit Ihrer Entscheidung, den Fehler zu
schließen, einverstanden ist, können Sie den Fehler neu öffnen, bis Sie eine
Vereinbarung gefunden haben, wie er gehandhabt werden soll. Falls Sie keine
finden, können Sie den Fehler mit wontfix
markieren,
damit die Leute wissen, dass der Fehler existiert, Sie ihn aber nicht
beheben möchten. Falls diese Situation nicht akzeptabel ist, können Sie
(oder der Absender) eine Entscheidung des technischen Ausschusses anfordern,
indem Sie den Fehler neu an tech-ctte
zuweisen (Sie könnten den Befehl
»clone« des BTS verwenden, falls Sie wünschen, dass der Fehlerbericht gegen
Ihr Paket weiterbesteht). Lesen Sie, bevor Sie dies tun, die empfohlene Prozedur.
Falls der Fehler zwar echt ist, jedoch ein anderes Paket betrifft, weisen
Sie ihn nur dem richtigen Paket neu zu. Falls Sie nicht wissen, an welches
Paket er zugewiesen werden soll, sollten Sie im IRC 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
<
vornimmt und Ihre Beweggründe für diese E-Mail erklären. Bitte beachten Sie,
dass ein einfaches erneutes Zuweisen nicht an den
Betreuer des Pakets versandt wird, an das zugewiesen wird, so dass er nichts
davon erfährt, bis er in die Fehlerübersicht seiner Pakete schaut.
Paketname
@packages.debian.org>
Falls der Fehler die Arbeit Ihres Pakets beeinflusst, denken Sie bitte daran, den Fehler zu klonen und den Klon dem Paket neu 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.
Manchmal müssen Sie außerdem den Schweregrad des Fehlers anpassen, so dass er der Debian-Definition entspricht. Dies geschieht deshalb, weil Leute die Schwere der Fehler aufblä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.
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ügt 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 alle anderen Absender von Berichten gesandt werden.) Weitere Details über die Form des »merge«-Befehls und dem verwandten Befehl »unmerge« finden Sie in der Dokumentation des BTS-Steuerungs-Servers.
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 so 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.
Falls sich der Fehler auf die Paketierung bezieht, beheben Sie ihn
nur. Falls Sie ihn nicht selbst beheben können, kennzeichnen Sie den Fehler
mit help
. Sie können außerdem auf <debian-devel@lists.debian.org>
oder <debian-qa@lists.debian.org>
um Hilfe ersuchen. Falls es ein Problem der
Originalautoren ist, müssen Sie es an die Originalautoren weiterleiten. Es
reicht nicht aus, den Fehler nur weiterzuleiten, Sie müssen bei jeder
Veröffentlichung prüfen, ob der Fehler behoben wurde oder nicht. Falls dies
der Fall ist, schließen Sie ihn, andernfalls müssen Sie den Autor später
daran erinnern. Falls Sie über die erforderlichen Fähigkeiten verfügen,
können Sie ein Patch vorbereiten, der den Fehler behebt und ihn dem Autor
mitschicken. Stellen Sie sicher, dass Sie das Patch an das BTS senden und
mit patch
kennzeichnen.
Falls Sie einen Fehler in Ihrer lokalen Kopie behoben haben oder eine
Fehlerbehebung in das VCS-Depot ü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 (dem
changelog
wird closes:
hinzugefügt). Dies ist besonders nützlich, falls Sie zusammen mit mehreren
Entwicklern am Paket arbeiten.
Sobald ein korrigiertes Paket im Archiv verfügbar ist, sollte der Fehler geschlossen und dei Version, in der er behoben wurde, angegeben werden. Dies kann automatisch geschehen – lesen Sie Abschnitt 5.8.4, „Wann Fehler durch neue Uploads geschlossen werden“.
Da 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: #
wird
bevorzugt, da sie die kürzeste Art des Eintrags ist und am einfachsten in
dem Text von XXX
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-part« genannt werden).
Früher wurden Uploads, die als Non-Maintainer Upload
(NMU) erkannt wurden, als fixed
statt als »closed«
gekennzeichnet, aber diese Praxis wurde mit dem Beginn der
Versionsverfolgung eingestellt. Das gleiche wurde mit der Markierung
fixed-in-experimental
getan.
Falls Sie sich bei der Fehlernummer vertippt haben oder einen Fehler in den
Änderungsprotokolleinträgen vergessen haben, zögern Sie nicht, jeglichen
durch den Fehler verursachten Schaden rückgängig zu machen. Um
fälschlicherweise geschlossene Fehler neu zu öffnen, senden Sie den Befehl
reopen
an die
Steuerungsadresse XXX
<control@bugs.debian.org>
der Fehlerdatenbank. Um irgendwelche
verbleibenden Fehler zu schließen, die durch Ihren Upload behoben wurden,
mailen Sie die Datei .changes
an
<
, wobei
XXX
-done@bugs.debian.org>XXX
die Fehlernummer ist und tragen Sie Version:
YYY
und eine leere Zeile als erste zwei Zeilen in
den Textteil der Mail ein, wobei YYY
die erste
Version ist, in der der Fehler behoben wurde.
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
<
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.
XXX
-done@bugs.debian.org>
Allgemeine Informationen über das Verfassen von Änderungsprotokolleinträgen
finden Sie unter Abschnitt 6.3, „Optimale Vorgehensweisen für debian/changelog
“.
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, Sicherheitswarnungen zu senden und
security.debian.org
zu verwalten.
When you become aware of a security-related bug in a Debian package, whether
or not you are the maintainer, collect pertinent information about the
problem, and promptly contact the security team by emailing
<team@security.debian.org>
. If desired, email can be encrypted with the Debian
Security Contact key, see https://www.debian.org/security/faq#contact for details. DO NOT UPLOAD any packages for
stable
without contacting the team. Useful information
includes, for example:
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 (Patchs sind besonders hilfreich)
jedes reparierte Paket, das Sie für sich selbst vorbereitet haben (senden
Sie nur die Dateien .diff.gz
und
.dsc
und lesen Sie zuerst Abschnitt 5.8.5.4, „Pakete vorbereiten, um Sicherheitsthemen anzugehen“)
jede Unterstützung, die sie zur Hilfe beim Testen anbieten können (Exploits, Regressionstest etc.)
jede Information, die für die zur Warnung nötig ist (siehe Abschnitt 5.8.5.3, „Sicherheitswarnungen“)
Als Betreuer des Pakets sind sie verantwortlich für dessen Verwaltung, sogar im Stable-Release. Sie sind in der besten Position, um Patchs zu beurteilen und aktualisierte Pakete zu testen, sehen Sie daher bitte in die folgenden Abschnitte, wie Pakete vorbereitet werden, damit sie vom Sicherheits-Team gehandhabt werden können.
Das Sicherheits-Team verwaltet eine zentrale Datenbank, die Debian-Sicherheits-Fehlerverfolgung. Diese enthält alle öffentlich verfügbaren Informationen, die über Sicherheitsthemen verfügbar sind: welche Pakete und Versionen betroffen oder repariert sind und ob daher Stable, Testing und/oder Unstable angreifbar sind. Informationen, die immer noch vertraulich sind, werden nicht zur Fehlerverfolgung hinzugefügt.
Sie können Sie 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, sie in Ihrem Paket zu behandeln. Anweisungen finden Sie auf dem Webseiten der Fehlerverfolgung.
Anders als bei den meisten Aktivitäten innerhalb von Debian, werden Informationen über Sicherheitsthemen eine Zeit lang geheim gehalten. Dies erlaubt es Software-Verteibern, 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 bereits eine Angelegenheit an die Öffentlichkeit gesickert 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, bittet, dass es nicht offengelegt wird, sollte diese Anfrage auf alle Fälle mit der einleuchtenden Ausnahme gewürdigt werden, das Sicherheits-Team zu informieren, damit der Fehler für ein Stable-Release von Debian erstellt 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-Depot) 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 aktivieren. Einzelheiten finden Sie in der Debian Sicherheits-FAQ.
Sicherheitswarnungen 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>
und an die Website Sicherheits-Informationen
geschickt. Sicherheitswarnungen werden vom Sicherheits-Team verfasst und
verschickt. Es macht natürlich nichts aus, wenn ein Paketbetreuer einige
Informationen dazu bereitstellen kann oder einen Teil des Textes
verfasst. Informationen in einer Warnung sollten Folgendes umfassen:
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 durch jemanden)?
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 reparierter Pakete
Informationen, woher man die aktualisierten Pakete bekommen kann (üblicherweise aus dem Debian-Sicherheitsarchiv)
Referenzen zu Warnungen der Originalautoren, CVE-Bezeichner und jede andere nützliche Informationen in Querverweisen zur Schwachstelle
Eine Möglichkeit, dem Sicherheits-Team bei seinen Aufgaben beizustehen besteht darin, es mit reparierten Paketen zu versorgen, die für eine Sicherheitswarnung des Stable-Releases geeignet sind.
Wenn eine Aktualisierung am Stable-Release vorgenommen wird, muss dies behutsam getan 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 Release 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 oder das ABI ä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 Sicherheitsreparatur zurück zu portieren, zum Beispiel, wenn große Teile des Quelltextes geändert oder überschrieben werden müssen. Falls dies geschieht, könnte es nötig sein, zu einer neue 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 Richtlinie: Testen Sie immer Ihre Änderungen. Falls Sie über ein Exploit verfügen, probieren Sie es aus und sehen Sie, ob es wirklich beim nicht reparierten Paket erfolgreich ist und am reparierten Paket scheitert. Testen Sie auch andere normale Aktionen, da eine Sicherheitsreparatur manchmal scheinbar nicht betroffene Funktionen auf raffinierte Weise stört.
Nehmen Sie KEINE Änderungen in Ihr Paket auf, die sich nicht direkt auf die Reparatur 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 Sicherheitswarnung 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 es 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ützlich Werkzeuge
dafür, siehe Abschnitt A.2.2, „debdiff“).
Überprüfen Sie unbedingt folgende Elemente:
Visieren Sie in Ihrem
debian/changelog
die richtige Version an:
Codename
-security
(z.B. wheezy-security
). Peilen Sie nicht
Distribution
-proposed-updates
oder stable
an!
Der Upload sollte die urgency=high haben.
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, fahren Sie aber 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 einen vorherigen Upload 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+deb7u1
und natürlich bei
nachfolgenden Uploads um eins zu erhöhen.
Sofern die Originalquelle 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 die Originalquelle 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
Sicherheitsfehlerbehebung später in die Hauptarchive zu verschieben.
Erstellen Sie das Paket auf einem einwandfreien
System, auf dem nur Pakete der Distribution installiert sind, für
die Sie es erstellen. Falls Sie selbst nicht über ein solches System
verfügen, können Sie eine debian.org-Maschine verwenden (siehe Abschnitt 4.4, „Debian-Maschinen“) oder richten Sie ein Chroot ein (siehe Abschnitt A.4.3, „pbuilder
“ und Abschnitt A.4.2, „debootstrap
“).
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 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 können.
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.
Einige Operationen zum Manipulieren von Archiven sind im Debian-Upload-Prozess nicht automatisiert. Diesen Prozeduren sollte manuell durch Paketbetreuer gefolgt werden. Dieses Kapitel gibt einen Leitfaden, was in diesen Fällen zu tun ist.
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.[3]
Falls Sie für eines Ihrer Pakete den Bereich ändern müssen, ändern Sie die
Paketsteuerungsinformation, um das Paket 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 es wird 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 Steuerungsdatei gefundenen Unterbereich
des Pakets und laden Sie es erneut hoch. Außerdem müssen Sie die Datei
»override« aktualisieren, wie es in Abschnitt 5.7, „Angabe des Paketbereichs, des Unterbereichs und der Priorität“
beschrieben wird.
Falls Sie aus irgendeinem Grund das 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
normalerweise den Schweregrad »normal« haben. Der Fehlertitel sollte die
Form RM:
haben, wobei
Paket
[Architekturenliste]
--
Grund
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
melden.
Falls Sie ein Paket entfernen wollen, das Sie betreuen, sollten Sie dies im
Fehlertitel 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 den
Abschnitt Abschnitt 5.13.2.2, „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 der Quelle 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, das das entfernte ersetzt.
Üblicherweise bitten Sie nur 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 O:
-Fehler
mit einem neuen Titel dem wnpp
-Paket neu zuweisen,
anstatt einen neuen Fehlerbericht als Bitte um Entfernen einzureichen.
Weitere Informationen über diese oder andere Themen, die sich auf das Entfernen von Paketen beziehen, können unter https://wiki.debian.org/ftpmaster_Removals und https://qa.debian.org/howto-remove.html gefunden werden.
Wenn Zweifel bestehen, ob ein Paket weggeworfen 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
aufgerufen wird, zeigt es Einzelheiten über das
Paket
Paket
, einschließlich umgekehrter
Abhängigkeiten. Andere nützlich Programme umfassen apt-cache
rdepends, apt-rdepends,
build-rdeps (im 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 einem
anderen Paket entwickelt wurde, neu 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.
Früher war es möglich, Pakete aus incoming
zu
entfernen. Mit der Einführung des neuen Incoming-Systems ist dies jedoch
nicht länger möglich. 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.
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
, damit Sie den neuen Namen
wiederspiegelt, ersetzt, bereitzustellt und zu dem veralteten Paketnamen 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 Abschnitt 5.9.2, „Pakete entfernen“). Vergessen Sie nicht, gleichzeitig die Fehler
ordnungsgemäß neu zuzuweisen.
Sonst könnten Sie einen Fehler beim Konstruieren Ihres Pakets begehen und
wünschen, es zu ersetzen. Die einzige Möglichkeit, dies zu tun besteht im
Erhöhen der Versionsnummer und dem Hochladen der neuen Version. Die alte
Version verliert wie üblich ihre Gültigkeit. Beachten Sie, dass dies auf
jeden Teil Ihres Pakets zutrifft, einschließlich der Quellen: Falls Sie den
Originalquell-Tarball Ihres Pakets ersetzen möchten, müssen Sie ihn mit
einer verschiedenen 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-Site einen einzigartigen Namen, der dabei
hilft, die Einheitlichkeit über ein Netzwerk von Spiegelservern
sicherzustellen.
Falls Sie ein Paket nicht länger betreuen können, müssen Sie andere
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 mit dem Titel O:
angeben, dass das Paket nun verwaist
ist. Der Schweregrad des Fehlers sollte auf Paket
-- kurze
Beschreibung
normal
gesetzt werden; falls das Paket die Priotität »standard« oder höher hat,
sollte er 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 Titel
RFA:
senden. Paket
-- kurze
Beschreibung
RFA
steht
für Request For Adoption
(Bitte um Adoption).
Weitere Informationen finden Sie auf den WNPP-Web-Seiten.
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 zu übernehmen, das vernachlässigt ist – das wäre Paketentführung. Sie können natürlich den aktuellen Betreuer kontaktieren und ihn fragen, ob Sie das Paket übernehmen dürfen. Falls Sie aus irgend einem Grund annehmen, der Betreuer sei AWOL (absent without leave/abwesend ohne etwas zu hinterlassen), dann lesen Sie Abschnitt 7.4, „Sich mit inaktiven und/oder nicht erreichbaren Paketbetreuern beschäftigen“.
Generell sollten Sie das Paket nicht ohne die Zustimmung des aktuellen Betreuers übernehmen. Sogar, wenn er Sie ignoriert, ist das immer noch kein Grund das Paket zu übernehmen. 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, die Aufmerksamkeit des Technischen Ausschusses darauf zu lenken (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 Upload
ein paar Tage dauern kann. Falls Sie für eine Weile nicht planen eine neue
Version hochzuladen, können Sie das Abschnitt 4.10, „Das Paketverfolgungssystem“
benutzen, um Fehlerberichte zu erhalten. Stellen Sie jedoch sicher, dass der
alte Betreuer kein Problem damit hat, dass Sie ab diesem Zeitpunkt die
Fehlerberichte erhalten.
Pakete werden oft aufgrund release-kritischer 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 kann im Element für das Entfernen im Bereich News der PTS-Seite des Pakets gefunden werden 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. Es gibt möglicherweise 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 erforderlichen Dinge tun, bevor Sie neue Pakete einführen (Abschnitt 5.1, „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 Schnappschussarchiv
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.
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 meisten Debian-Pakete
compilieren. 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
11 weitere Builds hinausläuft.
Portierer haben schwere und ungewöhnliche Aufgaben, da sie mit einer großen Zahl von Paketen umgehen müssen. Idealerweise sollte jedes Quellpaket richtig aus dem Stand erstellt werden. Unglücklicherweise ist das oft nicht der Fall. Dieser Abschnitt enthält eine Prüfliste von »Patzern«, die öfters von Debian-Betreuern begangen werden – übliche Probleme, die Portierer oft in die Klemme geraten lassen und ihre Arbeit unnötig erschweren.
Die Erste und Wichtigste ist es, schnell auf einen Fehler oder ein Problem zu antworten, das ein Portierer aufgetrieben hat. Behandeln Sie Portierer mit Höflichkeit, da Sie praktisch Mitbetreuer Ihres Pakets sind (was sie gewissermaßen sind). Bitte seien Sie tolerant bei knappen oder sogar unklaren Fehlerberichten. Tun Sie Ihr Bestes, um Jagd auf das zu machen, was auch immer das Problem ist.
Die mit Abstand meisten Probleme, die von Portierern gefunden werden, werden durch Paketierungsfehler in den Quellpaketen verursacht. Hier ist eine Prüfliste der Dinge, die Sie prüfen oder wissen sollten.
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 Abschnitt A.4.2, „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 im vom Paket
mit dem gleichen Namen bereitgestellt wird (sieheAbschnitt A.4.3, „pbuilder
“).
Falls Sie kein ordnungsgemäßes Chroot einrichten können, könnte Ihnen dpkg-depcheck behilflich sein (siehe Abschnitt A.6.6, „dpkg-depcheck“).
Anweisungen über die Einrichtung von Erstellungsabhängigkeiten finden Sie im Debian Policy Manual.
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.
Stellen Sie sicher, dass das Quellpaket korrekt ist. Führen Sie
dpkg-source -x
aus,
um sicherzustellen, dass Ihr Quellpaket ordnungsgemäß entpackt wird. Dann
versuchen Sie dort hinein Ihr Paket von Grund auf mit
dpkg-buildpackage zu erstellen.
Paket
.dsc
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.
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,
sogar wenn er die gleiche Architektur hat.
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 seine Sie sich bewusst, dass dies auf jeden Fall manuelles Bootstrapping erfordert und nicht durch automatisierte Paket-Builder erledigt werden kann.
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.
Sorgen Sie dafür, dass Ihre debian/rules
-Datei separate
binary-arch
- und binary-indep
-Targets
enthält, wie es das Debian Policy Manual erfordert. Stellen Sie sicher, dass
beide Targets unabhängig voneinander funktionieren, damit Sie ein Target
aufrufen können, ohne das Sie vorher das andere aufgerufen haben müssen. Um
dies zu prüfen, führen Sie dpkg-buildpackage -B aus.
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 compilieren zu können, führen Sie in Wirklichkeit ein Quell-NMU durch, ziehen Sie daher stattdessen Abschnitt 5.11.1, „Wann und wie ein NMU durchgeführt wird“ zu Rate.
Für einen Upload eines Portierern werden keine Änderungen an den Quellen
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
. Natürlich setzen Sie E-Mail des
Portierers
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.
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 compilieren 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 von der ersetzbaren Dpkg-Variable
$(Source-Version)
wechselseitige Abhängigkeiten erzeugen.
Ungeachtet der nötigen Modifikation des Änderungsprotokolls, werden diese rein binäre NMUs genannt – es ist nicht nötig in diesem Fall dafür zu sorgen, dass alle anderen Architekturen sich selbst als veraltet oder eines erneuten Compilierens bedürfig betrachten.
Solche Neu-Compilierungen 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 der Quelle. Falls Sie dabei einen Fehler machen, werden die Archivbetreuer Ihre Aktualisierung ablehnen (aus Mangel an entsprechendem Quellcode).
Die »Magie« für ein reines Neu-Compilierungs-NMU wird durch eine Endung
ausgelöst, die an die Paketversionsnummer angehängt wird und die Form
b
hat. Wenn etwa die
letzte Version, die Sie compilierten Zahl
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-Compilierungs-NMU), sollte Ihr
rein binärer NMU die Versionsnummer 3.4+b2
.[4] 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.
Portierer, die einen Quell-NMU durchführen, folgen generell den Richtlinien, die unter Abschnitt 5.11, „Non-Maintainer Uploads (NMUs)“ gefunden werden, 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 für die Einbindung in das nächste stabile 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 Richtlinien 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 der Policy steht, sondern nur
über Richtlinien vereinbart wurde.) Für Uploads nach
stable
oder testing
stimmen Sie sich
bitte zuerst mit dem Release-Team ab.
Zweitens sollten Protierer, die ein Quell-MMU 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 compilieren. 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 Patchs zu vermeiden, die einfache Bastellösungen
für Fehler in der aktuellen Version der Compiler-Umgebung, des Kernels oder
der Libc bieten. 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 aufder 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.
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.
Web-Seiten, die den Status jeder Portierung enthalten, können unter https://www.debian.org/ports/ gefunden werden.
Jede Portierung von Debian hat eine Mailingliste. Die Liste der Portierungs-Mailinglisten kann unter https://lists.debian.org/ports.html gefunden werden. Diese Listen werden benutzt, um die Arbeit der Portierer zu koordinieren und um eine Verbindung der Anwender der Portierung zu den Portierer herzustellen.
Beschreibungen von vielen Werkzeugen für die Portierung können unter Abschnitt A.7, „Portierungswerkzeuge“ gefunden werden.
Das System wanna-build
wird als ein
verteiltes Client-/Server-Build-Verteilungssystem benutzt. 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, das für die tatsächlichen
Paket-Builds benutzt wird, sbuild
,
ist als Paket verfügbar. Lesen Sie dessen Beschreibung unter Abschnitt A.4.4, „sbuild
“. Bitte beachten Sie, dass die Paketversion nicht der des
Build-Daemons entspricht, aber liegt ist nah genug bei dieser, 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 Untergeschmacksrichtungen von Debian, die von allgemeinem Interesse sein können oder auch nicht (zum Beispiel eine Debian-Geschmacksrichtung, die mit »bounds checking« von gcc erstellt wurde) zu erstellen. Dadurch wird Debian auch in die Lage versetzt, ganze Distributionen schnell neu zu compilieren.
Das Wanna-Build-Team, das für Buildds verantwortlich ist, ist unter
debian-wb-team@lists.debian.org
erreichbar. Um
festzustellen, wen (Wanna-Build-Team, Release-Team) Sie kontaktieren sollten
und wie (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.
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 kaputte 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) kaputte 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
any
auf 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
anzeigen.
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://buildd.debian.org/quinn-diff/Packages-arch-specific
verfügbar. Bitte lesen am Anfang der Datei, wer wegen der Änderungen
kontaktiert wird.
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 einige Binärpakete auf
nicht unterstützte Architekturen hochgeladen wurden, bitten Sie um Ihre
Entfernung, indem Sie einen Fehlerbericht gegen ftp.debian.org
einreichen.
Standardmäßig werden Pakete aus dem Bereich non-free
nicht durch das Autobuilder-Netzwerk gebaut (meistens, weil die Lizenz der
Pakete dem entgegen stehen könnte). Um zu aktivieren, dass ein Paket gebaut
wird, müssen Sie die folgenden Schritte durchführen:
Prüfen, ob es rechtlich erlaubt und technisch möglich ist, das Paket automatisch zu bauen;
XS-Autobuild: yes
zu den Kopfzeilen von
debian/control
hinzufügen;
eine E-Mail an <nonfree@release.debian.org>
senden und erklären, warum das Paket
rechtlich und technisch automatisch gebaut werden kann.
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, wenn der Betreuer Hilfe benötigt, um auf Probleme zu antworten. Solche Uploads werden Non-Maintainer Uploads (NMU) genannt.
Beachten Sie die folgenden Fragen, bevor Sie einen NMU durchführen:
Have you geared the NMU towards helping the maintainer? As there might be disagreement on the notion of whether the maintainer actually needs help on not, the DELAYED queue exists to give time to the maintainer to react and has the beneficial side-effect of allowing for independent reviews of the NMU diff.
Does your NMU really fix bugs? ("Bugs" means any kind of bugs, e.g. wishlist bugs for packaging a new upstream version, but care should be taken to minimize the impact to the maintainer.) Fixing cosmetic issues or changing the packaging style (e.g. switching from cdbs to dh) in NMUs is discouraged.
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: »Schaden Sie vor allem nicht«. Es ist besser, ein Paket mit einem offenen schweren Fehler zu belassen, als ein nicht funktionierendes Patch darauf anzuwenden oder eins, 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, falls Ihr NMU etwas kaputt macht.
Haben Sie Ihre Absicht, einen NMU durchzuführen, zumindest im BTS klar ausgedrückt? Es ist 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, Ihr Patch zu überprüfen und zu korrigieren, da sie potentielle Probleme kennen sollten, die demjenigen fehlen könnten, der den 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 einen NMU durchzuführen klar ist. Dann müssen Sie ein 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 das Patch vorbereiten, sollten Sie besser einige
paketspezifischen Verfahren kennen, die der Betreuer möglicherweise
benutzt. Ihn einzubeziehen verringert die Belastung, die Änderungen zurück
in den normalen Arbeitsablauf des Pakets zu integrieren und vergrößert daher
die Möglichkeit, dass das geschieht. Ein guter Ort, um etwas über die
paketspezifischen Methoden zu erfahren, ist debian/README.source
.
Sofern Sie keinen ausgezeichneten 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, die für Verzögerungen benutzt werden:
Der Upload behebt nur release-kritische 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 release-kritische Fehler behebt, die älter als sieben Tage sind: zwei Tage
Upload, der nur release-kritische Fehler und Fehler mit Schweregrad »important« behebt: fünf Tage
Andere NMUs: zehn Tage
Those delays are only examples. In some cases, such as uploads fixing
security issues, or fixes for trivial bugs that block a transition, it is
desirable that the fixed package reaches unstable
sooner.
Manchmal entscheiden Veröffentlichungsverwalter NMUs mit kürzeren Verzögerungen für eine Untermenge von Fehlern zu erlauben (z.B. release-kritische Fehler, die älter als sieben Tage sind). Außerdem führen manche Paketbetreuer sie selbst in der Liste LowThresholdNmu (niedrige Schwelle 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 das Patch vorher nicht im BTS verfügbar war oder falls Sie wissen, dass der Paketgetreuer allgemein aktiv ist.
Nachdem Sie einen NMU hochgeladen haben, sind Sie für mögliche Probleme verantwortlich, die Sie möglicherweise eingeleitet haben. Sie müssen das Paket im Auge behalten (ein gute Möglichkeit dies zu erreichen, ist es, das Paket im PTS zu abonnieren ).
Dies ist keine Lizenz, rücksichtslos NMUs durchzuführen. Falls Sie einen NMU auf den Weg bringen, wenn es klar ist, dass die Betreuer aktiv sind und ein 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.
Genauso wie jeder andere (Quell-) Upload, müssen NMUs einen Eintrag in
debian/changelog
hinzufügen, 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
sein, wobei X
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 würde der NMU die Version
1.5+nmu1
werden.
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 Maintainers 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 zeigt, dass 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
benutzt werden, wobei X
uY
X
die Major-Release-Nummer
und Y
eine fortlaufende, bei 1
beginnende Nummer ist. Während zum Beispiel Wheezy (Debian 7.0) 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+deb7u1
,
während ein Sicherheits-NMU für Jessie die Version
1.5-3+deb8u1
erhalten würde.
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 Abschnitt 5.6.2, „Verzögerte Uploads“) ermöglicht es einem Entwickler einen NMU und
alle nötigen Aufgaben gleichzeitig durchzuführen. Sie sollten zum Beispiel
anstatt dem Betreuer mitzuteilen, dass Sie das aktualisierte Paket in sieben
Tagen hochladen werden, das Paket nach DELAYED/7
hochladen und dem Betreuer mitteilen, dass er sieben Tage zum reagieren
hat. Während dieser Zeit kann der Betreuer Sie bitten, den Upload etwas
länger aufzuschieben oder Ihren Upload abzubrechen.
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.
Wenn jemand einen NMU Ihres Pakets dürchführt, bedeutet dies, dass er Ihnen helfen möchte, es in einem guten Zustand zu halten. Dies beschert den Anwendern schneller reparierte Pakete. Sie könnten überlegen, ob Sie denjenigen, der das 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.
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ührt, der erklärt, warum der Upload nötig war und die Versionsnummer
wird, wie in Abschnitt 5.10.2.1, „Neu compilieren oder rein binärer NMU“ beschrieben, erhöht. Dieser
Eintrag sollte nicht im nächsten Upload enthalten sein.
Buildds lädt Pakete für seine Architektur als rein binäre Uploads in das
Archiv. Genaugenommen sind dies binNMUs. Sie werden jedoch normalerweise
nicht als NMU bezeichnet und fügen debian/changelog
keinen Eintrag hinzu.
NMUs sind Uploads von Paketen durch jemand anderes als den ihnen zugewiesenen Betreuer. Es gibt noch einen anderen Upload-Typ, bei dem ihm das hochgeladene Paket nicht gehört: QS-Uploads. QS-Uploads sind Uploads verwaister Pakete.
QS-Uploads sind normalen Betreuer-Uploads sehr ähnlich: sie können alles
reparieren, 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 Abschnitt 5.9.5, „Adoption eines Pakets“).
Manchmal reparieren und/oder aktualisieren Sie ein Paket, weil Sie Mitglied
des Paketierungs-Teams sind (das als Maintainer
oder
Uploader
eine Mailingliste benutzt, siehe Abschnitt 5.12, „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 Richtlinien 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.
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 der grundlegenden
Zusammenstellung 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 Mitbetreuer mit Zugriff auf die Quellen ein, aus denen Sie
das Paket erstellen. Dies impliziert, dass Sie ein netzwerkfähiges
Versionskontrollsystem wie CVS
oder
Subversion
benutzen. Unter anderem stellt Alioth solche
Werkzeuge bereit (siehe Abschnitt 4.12, „Debians FusionForge-Installation: Alioth“).
Fügen Sie im Feld Uploaders
im ersten Absatz der Datei
debian/control
den korrekten Namen und die Adresse des
Mitbetreuers ein.
Uploaders: John Buzz <jbuzz@debian.org>, Adam Rex <arex@debian.org>
Wird das PTS (Abschnitt 4.10, „Das Paketverfolgungssystem“) benutzt, sollten sich die Mitbetreuer selbst für das entsprechende Quellpaket einschreiben.
Eine andere Form der gemeinschaftlichen Verwaltung stellt die
Team-Verwaltung dar. Sie 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:
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.
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 jedenfalls ein schlechter Einfall, automatisch alle Team-Mitglieder
in das Feld Uploaders
einzutragen. Es überfüllt die
Paketübersicht des Entwicklers (siehe Abschnitt 4.11, „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 Abschnitt 5.11.7, „NMUs gegenüber Team-Uploads“). Im umgekehrten Fall ist es eine
schlechte Idee ein Paket mit nur der Adresse der Mailingliste im Feld
Maintainer
zu behalten und keinen
Uploaders
.
Pakete werden normalerweise in die Distribution Testing installiert, nachdem
sie einem gewissen Maß von testing
in
unstable
unterzogen wurden.
Sie müssen auf allen Architekturen synchron sein sein und dürfen keine
Abhängigkeiten haben, die sie uninstallierbar machen; sie dürfen außerdem
zum Zeitpunkt, an dem sie in testing
installiert werden,
keine bekannten release-kritischen Fehler haben. Auf diese Art sollte
testing
immer ein potentieller Release-Kandidat
sein. Bitte lesen Sie das Folgende, um weitere Einzelheiten zu erfahren.
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 sie tun dies auf eine clevere
Art; sie versuchen jede Unstimmigkeit zu vermeiden und nur fehlerfreie
Pakete zu benutzen.
Die Aufnahme eines Pakets von unstable
ist durch
Folgendes bedingt:
Das Paket muss zwei, fünf oder zehn Tage in unstable
verfügbar gewesen sein, abhängig von der Dringlichkeit (hoch, mittel oder
niedrig). Bitte beachten Sie, dass die Dringlichkeit unnachgiebig ist, was
bedeutet, dass die höchste Dringlichkeit mit der seit dem letzten Übergang
nach testing
hochgeladen wurde, berücksichtigt wird.
Es darf keine veröffentlichungskritischen Fehler haben (release-kritische
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 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 Phase des Projekts. D.h. automatische Übergänge werden während des
Freeze der Distribution testing
ausgesetzt.
Um herauszufinden, ob ein Paket nach testing
fortschreitet oder nicht, sehen Sie 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, weshalb ein Paket abgelehnt wurde. Sie können es selbst
herausfinden, indem Sie schauen, was durch die Aufnahme des Pakets zerstört
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/ angezeigt — aber seien Sie gewarnt, diese Seite zeigt außerdem Build-Abhängigkeiten, die nicht von Britney berücksichtigt werden.
Für das testing
-Migrations-Skript bedeutet veraltet: Es
gibt in unstable
verschiedene Versionen für die
Release-Architektur (außer für Architekturen in Fuckedarches; Fuckedarches
ist eine Liste von Architekturen, die nicht weitergeführt werden (in
update_out.py
), aber gegenwärtig ist sie
leer). Veraltet hat nichts damit zu tun, welche Architekturen dieses Paket
in testing
unterstützt.
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 sich nicht nach
testing
ausbreiten.
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 so).
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 es in jedem anderen Sinn in Ordnung
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 release-kritischer Fehler reicht nicht aus, um diesen Status
zu bekommen).
Wenn ein Paket außerdem aus unstable
entfernt wurde und
kein Paket in testing
mehr davon abhängt, dann wird es
automatisch entfernt.
Eine Situation, die nicht sehr gut von Britney gehandhabt wird, 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.
Generell gibt es keine Bedeutung des Status eines Pakets in
testing
, der das Hinüberwechseln der nächsten Version
eines Pakets von unstable
nach testing
erfordert, mit zwei Ausnahmen: Falls ein Paket release-unkritischer wird,
könnte es sogar aufgenommen werden, wenn es immer noch release-kritisch
ist. Die zweite Ausnahme ist, wenn die Version des Pakets in
testing
auf den verschiedenene Architekturen nicht mehr
synchron ist: Dann könnte für jede Architektur nur ein Upgrade auf die
Version des Quellpakets durchgeführt werden; dies kann jedoch nur auftreten,
wenn das Paket vorher dorthin durchgedrängt wurde, die Architektur in
Fuckedarches ist oder kein binäres Paket dieser Architektur in
unstable
bei der Migration nach
testing
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.
Falls Sie die Einzelheiten interessieren, erklärt dies, wie Britney funktioniert:
Die Pakete werden betrachtet, um festzulegen, ob Sie gültige Kandidaten sind. Dies ergibt die Aktualisierungs-Ausreden. Die häufigsten Gründe, warum ein Paket nicht berücksichtigt wird lauten: zu neu, zu viele release-kritische Fehler und 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 Installierbarkeitstests 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://ftp-master.debian.org/testing/update_output/ nachsehen.
Die Hinweise sind unter https://ftp-master.debian.org/testing/hints/ verfügbar, wo Sie
auch die Beschreibung
finden können. Mit den Hinweisen kann das Debian-Release-Team Pakete
blockieren oder Blockaden aufheben, Pakete den Übergang nach
testing
erleichtern oder erzwingen, Pakete aus
testing
entfernen, das Hochladen nach testing-proposed-updates genehmigen oder die
Dringlichkeit außer Kraft setzen.
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 sie reglemäßig auf <debian-devel-announce@lists.debian.org>
erteilen.
Sie sollten nicht nach testing-proposed-updates
hochladen, wenn Sie Ihre Pakete über unstable
aktualisieren können. Falls Sie dies nicht können (zum Beispiel, weil Sie
eine neuere Entwicklerversion in unstable
haben), könnten
Sie diese Einrichtung nutzen, aber es ist empfohlen, dass Sie zuerst die
Veröffentlichungsverwalter um Erlaubnis fragen. Aktualisierungen über
unstable
sind sogar möglich, wenn ein Paket eingefroren
ist, falls der Upload über unstable
keine neuen
Abhängigkeiten mit sich bringt.
Versionsnummern werden normalerweise durch Hinzufügen einer fortlaufenden
Nummer zum Codenamen der testing
-Distribution gebildet,
wie 1.2squeeze1
für den ersten Upload über
testing-proposed-updates
der Paketversion
1.2
.
Bitte stellen Sie sicher, dass keines dieser Elemente in Ihrem Upload fehlt:
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 Anzahl von Änderungen eingefügt haben.
Sorgen Sie dafür, dass das Änderungsprotokoll eine entsprechende Erklärung enthält.
Überzeugen Sie sich, dass in Ihre Zieldistribution
testing
oder testing-proposed-updates
geschrieben 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
.
Nach dem Hochladen und erfolgreichen Erstellen auf allen Plattformen,
kontaktieren Sie das Team unter <debian-release@lists.debian.org>
und ersuchen Sie es
um Genehmigung Ihres Uploads.
Alle Fehler mit einem höheren Schweregrad werden standardmäßig als
release-kritisch 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
release-kritische Fehler hat, nicht nach testing
gelangen
und demzufolge nicht in stable
veröffentlicht werden.
Als unstable
-Fehleranzahl werden alle release-kritischen
Fehler gezählt, die als
Paket-
/Versions-
Kombinationen
zugehörig markiert sind, die in Unstable für eine Release-Architektur
verfügbar sind. Die Fehleranzahl in testing
ist sinngemäß
definiert.
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 zerstört, die davon abhängen.
Offenbar betrifft dies hauptsächlich Pakete, die ä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 zerstört, 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 kaputt gehen. Sobald alles bereit ist,
ist normalerweise ein manuelles Eingreifen des Veröffentlichungsverwalters
oder eines Assistenten nötig.
Falls Sie Probleme mit komplizierten Gruppen von Paketen wie diesem haben,
kontaktieren Sie <debian-devel@lists.debian.org>
oder <debian-release@lists.debian.org>
, um Hilfe
zu erhalten.
[3] Einen Leitfaden, in welchen Bereich ein Paket gehört, finden Sie im Debian Policy Manual.
[4] In der Vergangenheit benutzten solche NMUs die dritte Stufe im Debian-Teil der Revisionsnummer, um ihren Status als reine Neu-Compilierung anzuzeigen. Diese Syntax war jedoch bei nativen Paketen mehrdeutig und erlaubte keine ordnungsgemäße Einordnung von reinen Neu-Compilierungs-NMUs, Quell-NMUs und Sicherheits-NMUs im gleichen Paket. Daher wurden sie verworfen und diese neue Syntax bevorzugt.