openSUSE:Paketabhängigkeiten

Paketbau

Paketbau Richtlinien - Richtlinien zur Bezeichnung von Paketen - Richtlinien für Spezifikationsdateien - Richtlinien für Patches - Sicherheitsrichtlinien - Richtlinien für Paketgruppen - Paketbau Prüfungen - Kategorien für Desktopmenüs - RPM Makros - Init-Skripte - kleine Skript-Schnipsel - Paketbau Perl - Paketbau-Richtlinie für mehrfach benutzte Bibliotheken - Paketabhängigkeiten - Paketbau von Python-Software - Paketbau Richtlinien für mehrere Versionen

Wie führt man Distributionsaktualisierungen (upgrades) durch

Es gibt zwei Aktualisierungsmethoden, die ein unterschiedliches Herangehen erfordern

1. Fehlerbreinigungen (Patches)
2. Distributionsaktualisierungen

Mit der ersten Methode werden installierte Pakete geflickt, um Fehler zu beheben oder um fehlende Funktionen einzuführen. Die Paketversion bleibt gewöhnlich erhalten, nur die Pakeausgabenummer wird gändert. (Wenn das System openSUSE 12.1 ist, wird es auch openSUSE 12.1 bleiben)

Ebenso die Bauumgebung (Kompiler, Bibliotheken usw.) erkennt nur minimale Änderungen.

Die Distributionsaktualisierung (upgrade) hebt das komplette System auf eine neue Ebene. Die Betriebssystemversion wird erhöht. (Wenn das System beispielsweise openSUSE 12.1 heißt, wird es auf openSUSE 12.2 erhöht.) Die Paketänderungen, die während einer Distributionsaktualisierung erlaubt sind, sind viel stärker und schließen ein:

• weggefallene Pakete
• neue Pakete
• umbenannte Pakete
• zusammengeführte Pakete
• aufgetrennte Pakete

Solche Änderungen sind schwerer (oder sogar unmöglich) durch RPM-Abhängigkeiten auszudrücken. Darum wird eine ausdrücklichere Form von Paketabhängigkeiten benötigt, so dass die Distributionsaktualisierung durchgeführt werden kann.

Diese Wiki-Seite dokumentiert, wie Paketabhängigkeiten für Distributionsaktualisierungen auszudrücken sind.

Wenn Sie Abhängigkeiten zur nahtlosen Systemaktualisierung hinzufügen, vergessen Sie nicht, die openSUSE Version zu spezifizieren, wo dies gefordert ist. Es wird es erlauben, diese Zeilen in zukünftigen Versionen als veraltet zu erkennen (am wahrscheinlichsten könnte es die openSUSE Version +1 und SLE Version +2 sein).

Mittel zum Ausdruck von Abhängigkeiten

Jedes Paket kann Abhängigkeiten zu anderen Paketen ausdrücken, durch die Definition von symbolischen Bezeichnungen für Provides, Requires, and Conflicts.
Diese symbolischen Bezeichnungen sind gewöhnlich Namen von Paketen können aber ebenso 'abstrakte' Begriffe sein, die keine Bezug zu einem Paket haben.

Diese symbolischen Bezeichnungen können verwendet werden, um Möglichkeiten auszudrücken, die sich nicht auf ein spezielles Paket beziehen. Zum Beispiel, die Möglichkeit MTA ( mail transport agent) wird von mehreren Paketen unterstützt. Die bekanntesten sind sendmail und postfix.

Es ist wichtig, daran zu erinnern, dass alle symbolischen Bezeichnungen (ob es Pakete oder abstrakte Bezeichnungen sind) im gleichen Namensraum liegen. Wenn man eine abstrakte Bezeichnung wählt (z.B für eine Möglichkeit) darf es keinen Konflikt mit anderen Paketbezeichnungen geben.

Um Aktualisierungsabhängigkeiten auszudrücken, um ein altes Paket durch ein neues zu ersetzen, wird die Kennzeichnung Obsoletes verwendet.

Fakten zu RPM-Abhängigkeiten

• Jedes Paket trägt unbedingt eine Bezeichnung. Es gibt keine Notwendigkeit den Paketnamen bereitzustellen, aber andere Pakete können die Paketbezeichnung fordern (oder mit ihm in Konflikt geraten).
• Ein Paket kann nicht in Konflikt geraten mit einem symbolischen Merkmal, das es bereitstellt. Da die Paketbezeichnung unbedingt bereitgestellt wird, kann ein Paket nicht mit sich selbst in Konflikt geraten.
• Obsolete funktioniert nur bei wirklichen Paketbezeichnungen.
  Man kann keine symbolische Markierung auf veraltet setzen.
• Symbolische Bezeichnungen, die wie bei Requires, Provides und Conflicts verwendet werden sind case-sensitive.

Grundsätzliche Abhängigkeiten

Installation eines neuen Paketes

pac.spec
Name:	pac
Version:	1.0
Requires:
Provides:
Obsoletes:
Conflicts:

Aktualisierung eines Paketes

pac.spec
Name:	pac
Version:	1.1
Requires:
Provides:
Obsoletes:
Conflicts:

Die passende Bezeichnung und die höhere Version machen das zu einer Aktualisierung für pac-1.0

Umbenennung eines Paketes

package.spec
Name:	package
Version:	1.1
Requires:
Provides:	pac = %{version}
Obsoletes:	pac < %{version}
Conflicts:

Kurz gesagt, die alte Paketbezeichnung in das Feld Provides: einzusetzen ist nur erforderlich, wenn ein anderes Paket die alte Paketbezeichnung fordert. Bitte fügen Sie die Versionsnummer in das Feld mit der alten Paketbezeichnung hinzu, so dass eine spätere Umbenennung möglich ist. (Zum Beispiel: Provides: pac = 1.0). In 90% der Fälle können Sie  %{version} verwenden, wie in dem obigen Beispiel.

Der Eintrag Provides: löst die Auswahl des neuen Paketes während der Aktualisierung aus. Es ist das Feld, das sagt: Ich übernehme das alte Paket. Obsoletes: stellt einen winzigen Ersatz sicher, so dass keine Abhängigkeiten unterbrochen werden. Das Feld Version: ist hier irrelevant, aber Sie sollten ebenso die alte Paketversionsnummer zum Feld Obsoletes: hinzufügen (in diesem Beispiel Obsoletes: pac <= 1.0), um "den Weg zurück" zur alten Paketbezeichnung mit einer höheren Versionsnummer zu ermöglichen. Wie in dem Beispiel gezeigt wird, können Sie hier ebenso %{version} verwenden. Stellen Sie sicher, dass Sie in diesem Fall nur "<" verwenden. Andernfalls können Sie nicht zur alten Bezeichnung innerhalb der gleichen Version zurückkehren.

Wenn Sie ein Unterpaket mit einer anderen Versionsnummer als das Hauptpaket als veraltet erklären, können Sie nicht  %{version} in Provides/Obsoletes verwenden. Natürlich können Sie die gleiche Versionszeichenkette wie unter Version des Unterpakets verwenden.

Bitte fügen Sie auch einen einfachen Kommentar in die Spezifikationsdatei ein, z. B. "# pac wurde zuletzt verwendet in openSUSE 10.2". Ohne dieses wird es schwer sein, zu entscheiden, wann es möglich ist, diese Zeilen zu beseitigen. Andernfalls werden sie dort für immer stehen bleiben.

Ersetzen eines Paketes durch ein anderes mit der gleichen Funktionalität

package.spec
Name:	package
Version:	1.1
Requires:
Provides:
Obsoletes:	pac < %{version}
Conflicts:

Abgesehen von der Umbenennung eines Paketes wird pac durch package ersetzt. package unterstützt keine Dateien von pac.

Das funktioniert nur, wenn ein Paket nur pac veraltet. Wenn es mehrere Pakete gibt, wird der Solver diese Aktualisierung nicht ausführen.

Aufspaltung und Zusammenführung

Aufspaltung eines Unterpaketes

pac.spec			pac-devel.spec
Name:	pac		Name:	pac-devel
Version:	1.1		Version:	1.1
Requires:			Requires:
Provides:			Provides:	pac:/file/from/pac
Obsoletes:			Obsoletes:
Conflicts:			Conflicts:

Aufspaltung eines Paketes in zwei

firstpac.spec			secondpac.spec
Name:	firstpac		Name:	secondpac
Version:	1.1		Version:	1.1
Requires:			Requires:
Provides:	pac = 8.15		Provides:	pac:/file/from/pac
Obsoletes:	pac <= 8.15		Obsoletes:
Conflicts:			Conflicts:

Das gezeigte Beispiel listet getrennte .spec-Dateien für pac und pac-devel auf. (Erinnern Sie sich, dass RPM Unterpakete von einem 'Master'-Paket in einer einzigen .spec-Datei erlaubt.)

Die Abhängigkeitsauflösung (Installation beider neuen Pakete) wird von YaST mit dem split-alias, erwähnt in Provides: von pac-devel, ausgeführt.

Es ist Sache des Paketmaintainers über die Abhängigkeiten zwischen pac und pac-devel zu entscheiden. Wenn, zum Beispiel, jemand eine Bibliothekspaket aufspalten möchte in ein Hauptpaket, ein -devel und ein -doc-Paket. Das Hauptpaket und das -doc-Paket sind unabhängig, aber das -devel-Paket benötigt das Hauptpaket.

Während einer Aktualisierung ist das zuvor erwähnte Merkmal split-alias wichtig. YaST aktualisiert nur bereits installierte Pakete. In diesem Fall nur das Hauptpaket. Ohne das split-alias würde das Dateien löschen, die für die Entwicklung benötigt werden, die Teil des alten Hauptpaketes waren aber nicht im neuen Hauptpaket.

Das vorhandene Provides: für pac löst nun diese Aktualisierungsabhängigkeiten aus, da es YaST sagt, ebenso pac-devel zu installieren, obwohl es vorher nicht installiert war.

Warnung!Split-alias Markierungen werden nur von YaST verwendet, RPM sieht sie niemals.

Wenn ein Paket in mehr als zwei Pakete geteilt ist, muss die Markierung split-alias ausschließlich wechselseitig sein. Es ist der einzige Weg für YaST, solche Aktualisierungsabhängigkeiten korrekt zu handhaben.

Important enhancement for the future

Die Aufteilung eines Bibliothekspaketes in ein Haupt- und ein -devel-Paket ist immer eine gute Idee. Aber es macht nicht in jedem Fall Sinn - weil manchmal das -devel-Paket zu klein sein würde oder garnichts enthält. In diesem Fall fügen Sie nur Provides: pac-devel = %{version} in das Hauptpaket ein, was den folgenden Trick ausführt: andere Pakete können dieses virtuelle -devel-Paket anfordern.

Bitte fügen Sie einen einfachen Kommentar in die Spezifikationsdatei ein, beispielsweise "#-devel in openSUSE 12.1 aufgeteilt". Ohne dieses wäre es schwer zu entscheiden, wann es möglich ist, diese Zeilen zu löschen. Andernfalls würden sie da für immer stehen bleiben.

Zusammenführen eines Paketes

package.spec
Name:	package
Version:	1.1
Requires:
Provides:	pac = 8.15
Obsoletes:	pac <= 8.15
Conflicts:

Das ist vergleichbar mit der Umbenennung eines Paketes. Das neue Paket muss ebenso die Markierungen Provides und Obsoletes vom alten Paket einbeziehen. Das wird benötigt, um die Distribution vor X richtig zu aktualisieren.

Zusammenführen von zwei Paketen in ein neues

package.spec
Name:	package
Version:	1.1
Requires:
Provides:	pac1 = 8.15 pac2 = 2.3
Obsoletes:	pac1 <= 8.15 pac2 <= 2.3
Conflicts:

Handhabung von Alternativen

Keine Konflikte

firstpac.spec			secondpac.spec			thirdpac.spec
Name:	firstpac		Name:	secondpac		Name:	thirdpac
Version:	1.0		Version:	1.0		Version:	1.0
Requires:			Requires:			Requires:
Provides:	Pac = 1.0		Provides:	Pac = 1.0		Provides:	Pac 1.0
Obsoletes:			Obsoletes:			Obsoletes:
Conflicts:			Conflicts:			Conflicts:

Alle drei Pakete unterstützen die Fähigkeit Pac und können parallel installiert werden.

(Die Großschreibung von Pac wurde absichtlich gewählt, um diese Markierung von einem Paket zu unterscheiden. Solche Möglichkeiten müssen innerhalb der openSUSE Gemeinschaft bestätigt werden. Fragen Sie beim openSUSE-Paketbau nach, bevor Sie Ihre eigene Markierung erfinden!)

Beispiel: xdm und kdm unterstützen die Möglichkeit 'Display-Manager'

Teilweise Konflikt behaftet

firstpac.spec			secondpac.spec			thirdpac.spec
Name:	firstpac		Name:	secondpac		Name:	thirdpac
Version:	1.0		Version:	1.0		Version:	1.0
Requires:			Requires:			Requires:
Provides:	Pac = 1.0		Provides:	Pac = 1.0		Provides:	Pac = 1.0
Obsoletes:			Obsoletes:			Obsoletes:
Conflicts:	secondpac		Conflicts:	firstpac		Conflicts:

Das Conflicts drückt aus, dass nur entweder firstpac oder secondpac installiert sein könnte, aber nicht beide.

Ausschließlich manuell

firstpac.spec			secondpac.spec			thirdpac.spec
Name:	firstpac		Name:	secondpac		Name:	thirdpac
Version:	1.0		Version:	1.0		Version:	1.0
Requires:			Requires:			Requires:
Provides:	Pac = 1.0		Provides:	Pac = 1.0		Provides:	Pac = 1.0
Obsoletes:			Obsoletes:			Obsoletes:
Conflicts:	secondpac thirdpac		Conflicts:	firstpac thirdpac		Conflicts:	firstpac secondpac

Nur eines von firstpac, secondpac oder thirdpac könnte installiert sein.