Richtlinien für Konflikte

Beachten Sie, dass implizite Konflikte NIEMALS akzeptabel sind. Wenn Ihr Paket mit einem anderen Paket in Konflikt steht, müssen Sie den Konflikt entweder beheben oder ihn mit Conflicts: kennzeichnen.

Manche Software kann, falls vorhanden, weitere optionale Softwareanwendungen zur Nutzung heranziehen, benötigt diese aber nicht zwingend. Auch ohne deren Installation funktioniert die Software einwandfrei. Sind diese „optionalen Anwendungen“ jedoch zu alt, funktioniert die Software nicht. Dies ist ein zulässiger Anwendungsfall für das Feld Conflicts:. Der Paketierer muss den Grund dafür in einem Kommentar oberhalb des Feldes Conflicts: dokumentieren:

Beispiel:

Wenn die Software gegen die Bibliotheken eines anderen Pakets gelinkt ist, muss sie Requires: anstelle von Conflicts: verwenden, um diese Abhängigkeit zu kennzeichnen. Ebenso muss sie Requires: anstelle von Conflicts: verwenden, wenn die Software ohne die Installation eines anderen Pakets nicht ordnungsgemäß funktioniert.

Der Paketierer sollte sich Folgendes fragen:

Wenn das Paket (in der korrekten Version) unter „Conflicts:“ nicht aufgeführt ist, ist mein Paket dann noch funktionsfähig?

Lautet die Antwort „Ja“, dann ist die Verwendung von Conflicts: wahrscheinlich zulässig. Lautet die Antwort „Nein“, dann ist Requires: mit ziemlicher Sicherheit die bessere Wahl.

Wenn beispielsweise foo-game zum Ausführen libbar benötigt, aber nicht mit libbar-Versionen älter als 1.2.3 funktioniert:

FALSCH: Conflicts: libbar < 1.2.3
RICHTIG: Requires: libbar >= 1.2.3
Paketierer sollten die Verwendung von Conflicts: auf ein absolutes Minimum beschränken. Es wird nur eine Aktualisierung von zwei vorherigen Fedora-Versionen unterstützt. Daher sind Konflikte mit älteren Paketen zwar technisch korrekt, aber unnötig und sollten nicht aufgeführt werden.

Werden Inhalte eines Pakets in ein separates Paket ausgelagert, enthält das neue Paket üblicherweise Dateien, die auch im Originalpaket vorhanden sind. Dies kann zu einem impliziten Konflikt zwischen den Dateien im neuen und im Originalpaket führen. Wenn das neue Paket vom Originalpaket abhängt, lässt sich dies mit versionierten „Requires“ beheben:

Soll das neue Paket unabhängig davon installierbar sein, ob das Originalpaket installiert ist, ist ein versionierter Konflikt zulässig:

In beiden Fällen sollte die neue Version des Originalpakets aktualisiert werden, sodass sie die in Konflikt stehenden Dateien nicht mehr enthält und von dem neuen Paket abhängt (zumindest in allen stabilen Fedora-Versionen). Dadurch lassen sich die neuesten Versionen beider Pakete problemlos installieren. Die Konflikte dienen lediglich dazu, den Fall zu lösen, dass das neue Paket installiert wird und die ältere Version des Originalpakets bereits installiert war.

Die Verwendung von Conflicts: ist in bestimmten Fällen im Zusammenhang mit Kompatibilitätspaketen zulässig. Dies sind Fälle, in denen es nicht möglich ist, Anwendungen so zu patchen, dass sie an alternativen Speicherorten nach den -compat-Dateien suchen. In diesem Fall müssen die Pakete foo-devel und foo-compat-devel mit Conflicts: gekennzeichnet werden. Dies sollte jedoch nach Möglichkeit vermieden werden.

Falls mehrere Softwarekomponenten gleichnamige (aber inkompatible) Binärdateien erzeugen, sollten Fedora-Paketbetreuer alles daransetzen, die Upstream-Entwickler zur Umbenennung der Binärdateien zu bewegen, um den Konflikt zu beheben (siehe: Konflikte in Namen von Binärdateien). Wenn jedoch keiner der Upstream-Entwickler bereit ist, die Binärdateien umzubenennen UND die Binärdateien keine geeigneten Kandidaten für Alternativen oder Umgebungsmodule sind (inkompatible Laufzeitumgebungen), und solange keine eindeutigen Gründe für die gleichzeitige Installation beider Pakete vorliegen, sind explizite „Conflicts“ nach Ermessen des Paketbetreuers zulässig. In diesem Fall müssen beide Pakete „Conflicts“ enthalten.

Beachten Sie, dass das Hinzufügen expliziter „Conflicts“ dazu führen kann, dass andere Pakete, die von Ihrem Paket abhängen, eine Konfliktkette auslösen, die zu Problemen für die Benutzer führen kann. Bitte ziehen Sie das nur als letzten Ausweg in Betracht.

Wenn die Bibliothek vollständig ABI-kompatibel ist, können SieUmgebungsmodule verwenden, um dem Benutzer das Umschalten zwischen ihnen zu ermöglichen. Wenn die Bibliothek nicht vollständig ABI-kompatibel ist, fordern Sie einen der Upstream-Entwickler auf, den Namen zu ändern. Siehe Upstream-Ansprachefür Ideen zur Überzeugung. Wenn keiner der Upstream-Entwickler nachgibt, erstellen Sie ein Ticket für das Fedora Packaging Committee, damit dieses prüft, welche zusätzlichen Maßnahmen beide Pakete ergreifen müssten, um Laufzeitkonflikte zu vermeiden.

Beim Umbenennen oder Verschieben von Dateien in Unterverzeichnisse ist es ratsam, die Upstream-Entwickler zu bitten, die in Konflikt stehenden Dateien umzubenennen (z.B. wenn beide Befehle mit dem Namen %{_bindir}/trash enthalten). Recherchen darüber, welche Version länger existiert, können in diesem Fall hilfreich sein, sind aber möglicherweise nicht überzeugend genug für die Upstream-Entwickler.

Wenn keiner der Upstream-Entwickler die Pakete umbenennt, würden wir uns an andere Distributionen wenden (distributions-list[at]freedesktop.org ist ein guter Ort, um dies zu besprechen), um eine Umbenennung in allen Distributionen zu erzielen. Dies hilft Endbenutzern, die zwischen verschiedenen Distributionen wechseln, für mehr Konsistenz zu sorgen. Die Dauer des Bestehens der Projekte, ihre Popularität und zahlreiche weitere Faktoren können bei dieser Entscheidung eine Rolle spielen. Sobald eine Entscheidung getroffen wurde, würden wir die Fedora-Pakete entsprechend umbenennen.

Für Standardbefehle sind gebräuchliche Namen zulässig, da nur diese die Befehle implementieren. Standardbefehle umfassen Funktionen, die in veröffentlichten und weit verbreiteten Standards wie POSIX und De-facto-Standards definiert sind, beispielsweise Programme, die traditionell mit einem bestimmten Dateinamen als Teil zahlreicher Unix-Varianten ausgeliefert werden. Im Zweifelsfall senden Sie bitte eine Nachricht an fedora-devel-list[at]redhat.com mit folgenden Angaben: In welchen Standards der Befehl enthalten ist, wie lange er auf welchen Unix-Systemen verfügbar ist und ob Sie Programme gefunden haben, die einen wesentlich anderen Befehl mit demselben Dateinamen implementieren.