Fedora-Paketquellen

Bei stabilen Releases repräsentiert fedora den eingefrorenen Veröffentlichungsstatus. Es ist Teil des eingefrorenen Baums, der von Release Engineering erstellt wird, sobald eine Veröffentlichung in einem Go/No-Go-Meeting genehmigt wurde. Die darin enthaltenen Pakete ändern sich danach niemals mehr. Es repräsentiert den stable Status einer stabilen Veröffentlichung in Verbindung mit der updates-Paketquelle.

Die fedora-Paketquellen der stabilen Veröffentlichung für die verschiedenen Hauptarchitekturen befinden sich im Verzeichnis /fedora/linux/releases/XX/Everything auf den Spiegelservern (wobei XX für die Veröffentlichungsversion steht) und können auch über MirrorManager abgefragt werden. Beispielsweise liefert https://mirrors.fedoraproject.org/mirrorlist?repo=fedora-43&arch=x86_64 Spiegelserver für die x86_64-Paketquelle von fedora für die Veröffentlichungsversion 43.

Bei verzweigten Veröffentlichungen – dem Zustand zwischen der Verzweigung von Rawhide und der stabilen Version (siehe Branched für weitere Details) – repräsentiert allein die fedora-Paketquelle den stabilen Zustand der Version. Die Paketquelle updates wird für verzweigte Veröffentlichungen erst dann verwendet, wenn diese stabil sind. Vor der Aktivierung von updates-testing werden Paket-Builds für die verzweigte Veröffentlichung direkt an diese Paketquelle gesendet. Nach der Aktivierung von Bodhi werden Paket-Builds, die die Aktualisierungsrichtlinie erfüllen, aus der Paketquelle updates-testing in diese Paketquelle verschoben.

Die verzweigten fedora-Paketquellen für die verschiedenen primären Architekturen befinden sich im Verzeichnis /fedora/linux/development/XX auf den Spiegelservern (wobei XX die jeweilige Version angibt) und können auch über MirrorManager abgefragt werden. Beispielsweise liefert https://mirrors.fedoraproject.org/mirrorlist?repo=fedora-44&arch=x86_64 Spiegelserver für die x86_64-Paketquelle fedora für die Version 44.

Die Paketquelle updates-testing existiert für verzweigte Veröffentlichungen nach der Aktivierung durch Bodhi sowie für stabile Veröffentlichungen. Sie ist für DNF in der Datei fedora-updates-testing.repo im Paketquellenpfad zu finden. In beiden Fällen dient sie als Testumgebung, in der neue Paket-Builds geprüft werden, bevor sie als stabil markiert und somit in die Paketquelle_fedora_ bzw. updates verschoben werden.

Diese Builds werden manchmal als update candidates bezeichnet und werden gemäß den Richtlinien für Aktualisierungs-Feedback mit dem Aktualisierungs-Feedback-Werkzeug Bodhi überprüft.

Die Aktualisierungsrichtlinien definieren die Regeln für die Kennzeichnung von Aktualisierungskandidaten als stable. Die Seite QA updates-testing bietet Testern Informationen zur Verwendung dieser Paketquelle. Der Leitfaden für Paketaktualisierungen enthält Informationen für Paketierer zum Einreichen von Builds für updates-testing und stable.

Die Paketquelle_updates-testing_ ist für verzweigte Veröffentlichungen standardmäßig aktiviert, für stabile Veröffentlichungen jedoch deaktiviert. Die Umstellung erfolgt etwa zum Zeitpunkt des jeweiligen endgültigen Einfrierens Final Freeze) . Tester, die von einer verzweigten auf eine stabile Version wechseln, können in diesem Zeitraum auf Fehler beim Anwenden von Aktualisierungen stoßen. Diese Fehler werden durch Abhängigkeitskonflikte zwischen Paketen verursacht, die bereits aus der nun deaktivierten Paketquelle updates-testing installiert wurden. Die Ausführung von dnf distro-sync oder die Reaktivierung der Paketquelle updates-testing behebt das Problem in der Regel. Es liegt im Ermessen des jeweiligen Benutzers, ob er die Paketquelle updates-testing nach der stabilen Veröffentlichung weiterhin verwenden möchte.

Die updates-testing-Paketquellen für sowohl verzweigte als auch stabile Veröffentlichungen befinden sich im Verzeichnis /fedora/linux/updates/testing/XX auf den Spiegelservern (wobei XX für die Veröffentlichungsversion steht) und können auch über MirrorManager abgefragt werden. Beispielsweise liefert https://mirrors.fedoraproject.org/mirrorlist?repo=updates-testing-f43&arch=x86_64 Spiegelserver für die x86_64-updates-testing-Paketquelle für die Veröffentlichung 43.

In Rawhide – der Rolling-Release-Paketquelle von Fedora, aus der Veröffentlichungen abgezweigt werden, bevor sie als stabil gelten – ist rawhide die einzige Paketquelle. Alle Paket-Builds werden dorthin gesendet. Sie ist für DNF in der Datei fedora-rawhide.repo im Paketquellenpfad aufgeführt. Für jedes System, auf dem Rawhide läuft, sollte sie aktiviert sein. Für alle anderen Systeme sollte sie deaktiviert sein.

Die rawhide-Paktequellen für die verschiedenen primären Architekturen befinden sich im Verzeichnis auf den Spiegelservern und können auch über MirrorManager abgefragt werden. Beispielsweise liefert https://mirrors.fedoraproject.org/mirrorlist?repo=fedora-rawhide&arch=x86_64 Spiegelserver für die x86_64 fedora-Paketquelle für Rawhide.

Es ist nicht ungewöhnlich, von einer „stabilen Paktequelle“ zu lesen, aber diese Bezeichnung ist etwas irreführend. „Stabil“ beschreibt eher einen Zustand, der sowohl für verzweigte Veröffentlichungen nach der Aktivierung durch Bodhi als auch für stabile Veröffentlichungen gilt. Er umfasst Paket-Builds, die zum Zeitpunkt der Verzweigung Teil von Rawhide waren, Paket-Builds, die zwischen dem Verzweigungspunkt und der Aktivierung von Bodhi direkt an die verzweigte fedora-Paketquelle gesendet wurden, sowie Paket-Builds, die die Anforderungen der Aktualisierungsrichtlinie erfüllten und nach der Aktivierung von Bodhi aus updates-testing verschoben wurden.

Bei verzweigten Veröffentlichungen wird der stable-Zustand ausschließlich durch den aktuellen Inhalt der fedora-Paketquelle repräsentiert (und möglicherweise auch durch den der bleed-Paketquelle, aber das ist ein seltener Fall).

Bei stabilen Veröffentlichungen wird der stable-Zustand durch den Inhalt der fedora-Paketquelle in Kombination mit dem Inhalt der updates-Paketquelle repräsentiert.

stable ist auch ein Zustand, in dem sich ein Paket befinden kann (oder ein Attribut, das es haben kann), wenn es pushed stable oder tagged stable ist und sich in einer stable-Paketquelle für eine Veröffentlichung befindet oder sich bald darin befinden wird - welche Paketquelle auch immer gemeint ist (siehe oben).

Die Paketquelle bleed dient einem einzigen Zweck: Während der Milestone-Freezes enthält sie Pakete, denen über den Blocker-Bug-Prozess) oder den Freeze-Exception-Bug-Prozess Ausnahmen vom Freeze gewährt wurden und die in den nächsten Test-Compose- oder Release-Candidate-Build aufgenommen werden sollen, aber noch nicht den Status stable erreicht haben und daher in die Paketquelle fedora verschoben wurden. Anders ausgedrückt: Sie enthält Pakete, die explizit für Compose Requests benötigt werden.

Die bleed-Paketquelle ist hier zu finden, dürfte aber für die meisten Fedora-Nutzer eher irrelevant sein. Die darin enthaltenen Pakete sind stets auch über das Build-System Koji und üblicherweise über die Paketquelle updates-testing verfügbar.

Die latest Paketquellen enthalten Pakete für verschiedene Build-Tags, sobald diese im Koji-Bausystem verfügbar sind. Sie sind nicht mit mashed identisch, einem Prozess, der hauptsächlich Multilib-Bibliotheken verwaltet. Die Verwendung dieser Paketquellen kann neben der Überlastung der Fedora-Entwicklungsserver auch verschiedene andere Probleme verursachen. Es empfiehlt sich daher fast immer, neue Builds von Koji oder Bodhi über deren Web-Oberflächen oder Befehlszeilenwerkzeuge zu beziehen.

Wie oben beschrieben, durchlaufen Aktualisierungen sowohl für verzweigte Vorabveröffentlichungen als auch für finale, stable-Veröffentlichungen den updates-testing-Prozess, bevor sie in eine stable-Paketquelle verschoben werden. Vor der finalen Veröffentlichung werden sie in der fedora-Paketquelle abgelegt. Nach der Veröffentlichung landen sie in updates.

Der Unterschied liegt darin begründet, dass wir den genauen „Status“ einer bestimmten stabilen Fedora-Version dokumentieren möchten. Das heißt, zum Zeitpunkt der Veröffentlichung einer Fedora-Version im Rahmen eines Go/No-Go-Meetings betrachten wir den Status dieser Version als deren endgültige Definition und möchten diesen Status dokumentieren. Für eine stabile Version ist der Verzeichnisbaum, der die Paketquelle fedora enthält, diese Dokumentation, und die darin enthaltene Paketquelle fedora ist die endgültige Dokumentation des exakten, eingefrorenen (frozen) Paketsatzes, der den Hauptteil dieser stabilen Version bildete.

Da wir den frozen-Zustand der fedora-Paketquelle beibehalten möchten, können wir Aktualisierungen nicht direkt dort einfügen. Die Notwendigkeit der updates-Paketquelle wird daher deutlich – wir benötigen einen Ort, an dem wir Aktualisierungen stabiler Versionen außerhalb des frozen-Zustands der jeweiligen Veröffentlichung bereitstellen können.

Vor einer stabilen Veröffentlichung ist dieser Mechanismus nicht notwendig. Bevor die Veröffentlichung als abgeschlossen erklärt wird, gibt es keinen frozen-Zustand: Der gesamte Verzweigungs-Entwicklungsprozess arbeitet effektiv auf den endgültigen Zustand der Veröffentlichung hin, so dass die Paket-Builds für die verzweigte Version direkt in der fedora-Paketquelle landen.

Während sowohl verzweigte Entwicklungsversionen als auch stabile Versionen eine updates-testing-Paketquelle zusammen mit dem Bodhi-Update-Feedbacksystem verwenden, um Pakete zu stagen, bevor sie den stable-Status der Veröffentlichung erreichen, ist dies bei verzweigten Veröffentlichungen standardmäßig aktiviert, bei stabilen Veröffentlichungen jedoch nicht.

Der Grund dafür ist, dass das updates-testing-System je nach Fall unterschiedliche Zwecke verfolgt. Bei stabilen Veröffentlichungen dient es dazu, fehlerhafte Aktualisierungen für die allgemeine Fedora-Nutzerschaft zu verhindern. In den meisten Fällen ist die updates-testing-Paketquelle auf Fedora-Systemen deaktiviert. Einige QA-Tester aktivieren die Paketquelle jedoch auf Testsystemen, um die Aktualisierungen zu testen und Feedback zu geben. Die Tester stellen sicher, dass die Aktualisierungen einwandfrei funktionieren, bevor sie an die allgemeine Nutzerschaft verteilt werden.

Bei einer Vorabveröffentlichung aus einer Verzweigung wird erwartet, dass jeder, der sie installiert, beim Testen mithilft: Wir betrachten jeden, der eine verwzweigte Veröfentlichung nutzt, als Tester. Die Funktion von updates-testing ist in diesem Fall anders. Es gibt keine „allgemeine Benutzergruppe“ einer verzweigten Veröffentlichung, die updates-testing deaktiviert hat und durch die Gruppe der Aktualisierungstester vor problematischen Aktualisierungen geschützt wird. Stattdessen erfüllt updates-testing in verzweigten Veröffentlichungen andere wichtige Funktionen.

Der Hauptzweck besteht darin, Image-Builds vor potenziell problematischen Änderungen zu schützen. Verzweigte Images – Nightly Images sowie die Alpha-, Beta- und GA-Meilenstein-Builds (Final) und ihre Test-Compose- und Release-Candidate-Builds – werden aus den stable-Paketen erstellt, also ausschließlich aus denen in der fedora-Paketquelle, nicht aus denen in updates-testing. In diesem Sinne schützt updates-testing nicht eine Gruppe von Benutzern, sondern eine Gruppe von Builds vor potenziell destabilisierenden Änderungen. Insbesondere beim Erstellen einer Alpha-, Beta- oder GA-Version müssen wir die Anzahl der Änderungen im Paketset zwischen den Compose-Builds minimieren, um ein qualitativ hochwertiges Image zu erzeugen. Der Mechanismus updates-testing ermöglicht dies: Während Milestone-Freezes) können neue Builds an updates-testing gesendet werden, dürfen aber ohne besondere Umstände nicht von dort in stable (fedora) verschoben werden. So können wir an Veröffentlichungs-Images arbeiten, ohne die Paketierer am Veröffentlichen von Builds zu hindern.

Für diese und andere weniger wichtige Funktionen benötigen wir so viel Feedback wie möglich. Daher ist es sinnvoll, dass alle Tester der Vorabveröffentlichung standardmäßig updates-testing aktiviert haben und dazu angehalten werden, Feedback über Bodhi zu geben.

See a typo, something missing or out of date, or anything else which can be improved? Edit this document at https://forge.fedoraproject.org/docs/quick-docs.