Prozess zum Stilllegen von Paketen

Wenn ein Paket das Ende seiner Nutzungsdauer erreicht hat, informiert der Prozess zum Stilllegen von Paketen andere Personen – und automatisierte Prozesse! – darüber, dass keine weiteren Veröffentlichungen mehr zu erwarten sind und warum das Paket entfernt wurde. Dieser Prozess ist in der Richtlinie für verwaiste und stillgelegte Pakete geregelt.

Eine häufige Situation, die unter anderem die Stilllegung eines Pakets beinhaltet, ist die Umbenennung eines Pakets oder dessen Ersetzung durch ein anderes mit kompatibler Funktionalität. Informationen zum Umgang mit solchen Situationen finden Sie in den entsprechenden Paketbaurichtlinien.

Was stillgelegt werden kann

Pakete können normalerweise nur in den folgenden Zweigen stillgelegt werden:

Rawhide
Branched (bis zum „Final Freeze“)
EPEL-Zweige (epel7, epel8, epel9 und die entsprechenden -next-Zweige) – siehe EPEL-Stilllegungsrichtlinie für weitere Erfordernisse

Vorgehensweise

Bitte führen Sie die folgenden Schritte in der angegebenen Reihenfolge aus.

RPM

Wenn das Paket durch ein anderes Paket ersetzt wird, stellen Sie sicher, dass die Obsoletes/Provides-Tags vom neuen Paket gemäß den Richtlinien zum Umbenennen/Ersetzen oder Entfernen vorhandener Pakete korrekt gesetzt werden.

Git

Führen Sie in Rawhide den Befehl fedpkg retire DESCRIPTION aus. Die DESCRIPTION sollte erklären, warum das Paket entfernt wurde. Beispiele für aussagekräftige Meldungen sind Obsoleted by <neues_Paket> und Renamed to <neues_Paket>.

fedpkg retire entfernt alle Dateien aus dem Zweig, fügt die Datei dead.package hinzu, die DESCRIPTION enthält, und pusht die Änderungen.

Falls „Branched“ bereits existiert und der „Final Freeze“ noch nicht begonnen hat, verhindern Sie die Veröffentlichung des Pakets, indem Sie den Commit zur Paketfreigabe in diesen Zweig mergen (oder per Cherry-Pick übernehmen usw.). Es ist nicht notwendig, fedpkg retire separat für „Branched“ auszuführen.

Führen Sie fedpkg retire nicht für einen unterstützten oder abgekündigten Fedora-Release-Branch aus oder mergen einen Stilllegungs-Commit. Pakete dürfen nicht aus stabilen Veröffentlichungen entfernt werden.

Wenn das Paket in EPEL enthalten ist, beachten Sie auch EPEL-Stilllegungsrichtlinien.

fedora-obsolete-packages

Überlegen Sie, was mit Systemen geschieht, auf denen die nun veralteten Pakete installiert sind. Im Allgemeinen bleiben diese Pakete einfach auf dem System erhalten und veralten mit der Zeit. Sollte dies nicht akzeptabel sein, beispielsweise aufgrund von Problemen mit dem Aktualisierungspfad oder bei Sicherheitsbedenken, fügen Sie Ihr Paket zu fedora-obsolete-packages hinzu.

Comps

Entfernen Sie ihr Paket aus Comps, falls es dort gelistet ist.

Spins

Entfernen Sie Ihr Paket aus den Kickstart-Dateien der Spins.

Koji

Um zu verhindern, dass stillgelegte Pakete auf die Spiegelserver übertragen werden, müssen sie in Koji gesperrt werden. Dies geschieht automatisch beim nächsten Compose-Vorgang (für Rawhide, die verzweigte Version und EPEL).

Sie können mit koji list-pkgs --show-blocked überprüfen, ob ein Paket in Koji blockiert ist. Für jeden Zweig, in dem das Paket stillgelegt wurde, sollte ein Eintrag mit [BLOCKED] vorhanden sein. Es genügt, wenn ein Paket in einem älteren Tag blockiert ist, da es aufgrund eines Vererbungsmechanismus auch in einem neueren Tag blockiert ist. Beispielausgabe:

$ koji list-pkgs  --show-blocked --tag f42 --package curry
Package                 Tag                     Extra Arches     Owner
----------------------- ----------------------- ---------------- ---------------
curry                   f41                                      gemi            [BLOCKED]

Bitte warten Sie zwei Tage, bis der Vorgang abgeschlossen ist und die Spiegelserver aktualisiert werden können. Falls das Paket nach zwei Tagen nicht automatisch blockiert wird, erstellen Sie bitte ein Ticket für Release Engineering und geben Sie die Paketnamen sowie die Zweige an, in denen die Pakete blockiert werden sollen. Verwenden Sie bitte nur ein Ticket für alle Pakete, die Sie gleichzeitig stillgelegt haben. Erstellen Sie nicht für jedes Paket ein separates Ticket, falls Sie mehrere Pakete stillgelegt haben.

EPEL

Der Stilllegungsprozess kann auch für EPEL angewendet werden, jedoch mit einem Unterschied:

Sie können das Paket aus jedem EPEL-Zweig entfernen, unabhängig davon, ob dieser bereits veröffentlicht wurde oder nicht.

Wenn Ihr Paket beispielsweise in RHEL-9.4 zur RHEL-Basis hinzugefügt wurde, führen Sie die oben genannten Schritte aus, verwenden Sie jedoch den Zweig el9 anstelle von rawhide.

Wenn Sie ein Paket aus EPEL zu einer beliebigen RHEL-Version hinzufügen müssen, sollten Sie den EPEL-Zweig erst dann stilllegen, wenn das Paket in dieser RHEL-Version veröffentlicht wurde.

Wiederaufnahme der Betreuung eines stillgelegten Pakets

Wenn Sie die Betreuung eines stillgelegten Pakets weiterführen möchten, sollten Sie sich darüber im Klaren sein, dass die Behebung kritischer Fehler usw. in Ihre Verantwortung fällt, falls das Upstream-Projekt nicht mehr gepflegt wird. Dies dient dazu, die hohe Qualität und die Standards der Paketverwaltung für die Fedora-Paketsammlung zu gewährleisten. Bei stillgelegten Paketen können zusätzliche Probleme auftreten. Wenden Sie sich nach Möglichkeit an den ehemaligen Betreuer, um weitere Informationen zu erhalten. Der Prozess unterscheidet sich etwas von der Wiederherstellung eines verwaisten Pakets.

Versuchen Sie herauszufinden, warum das Paket stillgelegt wurde. Suchen Sie dazu auf der devel-Mailingliste nach Informationen zu verwaisten Paketen oder kontaktieren Sie den ehemaligen Betreuer per E-Mail. Sie können auch die Datei dead.package im SCM überprüfen (URL z.B.: https://src.fedoraproject.org/rpms/Paketname_hier/blob/rawhide/f/dead.package)
Geben Sie auf der devel-Mailingliste bekannt, für welche Pakete Sie die Eigentümerschaft übernehmen möchten.
Stillgelegte Fedora-Pakete (ausgemusterter Rawhide-Zweig stillgelgt) müssen erneut geprüft werden, wenn sie länger als acht Wochen im Stilllegungsprozess sind oder noch keine Prüfung stattgefunden hat. Reichen Sie eine Review-Anfrage (ein neues Bugzilla-Ticket) ein und lassen Sie das Paket von einem Prüfer genehmigen, als wäre es neu in Fedora. Weitere Informationen finden Sie in der Dokumentation zum Paket-Review-Prozess. Um einen EPEL-Zweig wieder zu aktivieren, solange das Paket noch in Fedora verfügbar ist, ist keine erneute Prüfung erforderlich.
Beantragen Sie die Aufhebung der Stillegung, indem Sie ein Release-Engineering-Ticket einreichen. Geben Sie alle Zweige an, die reaktiviert werden sollen (einschließlich rawhide für Rawhide, es sei denn, es handelt sich ausschließlich um EPEL), und fügen Sie den Link zum erneuten Review hinzu. Bitten Sie in diesem Ticket das Release-Engineering-Team, das Paket für die entsprechenden Veröffentlichungen freizugeben. Geben Sie in Ihrem Antrag genau an, welche Zweige freigegeben werden sollen.
Stellen Sie den Inhalt in Git wieder her und bereiten Sie einen neuen Build und eine Aktualisierung vor (falls erforderlich).

Ein Paket vollständig entfernen

In seltenen Fällen, beispielsweise nach der Entdeckung von Lizenzproblemen, kann es erforderlich sein, ein Paket vollständig aus Fedora zu entfernen. Dies unterscheidet sich von der regulären Außerbetriebnahme dadurch, dass das Paket auch aus stabilen und auslaufenden Versionen entfernt wird.

Für eine vollständige Entfernung befolgen Sie zunächst die Vorgehensweise für das normale Entfernen.

Zusätzlich sollte das Paket aus allen dist-git-Zweigen entfernt werden. Da fedpkg retire in stabilen Zweigen nicht funktioniert, kann dies wie folgt simuliert werden:

$ DESC="meine_Beschreibung"; git rm -r . && echo "$DESC" > dead.package && git add dead.package && git commit -m "$DESC"

Zum Schluss fügen Sie das Paket zu fedora-obsolete-packages hinzu.

Want to help? Learn how to contribute to Fedora Docs ›