Patch-Verwaltung/Code11

aus openSUSE, der freien Wissensdatenbank

Code11 Patches & Aktualisierungen

Diese Seite beschreibt die Basiskonzepte von Patches und Aktualisierungen für Code11.

Gewährleistungsauschluss

Diese Seite beschreibt das Konzept. Nicht alles davon ist in openSUSE 11.0 implementiert und manches davon wird es nie sein.

Terminologie

Dies ist die Terminologie, die in der folgenden Beschreibung genutzt wird.

• Aktualisierung - eine einzelnes Ersatzpaket (eine neuer Paketversion)
• Patch - Informationen über Aktualisierungen, information about updates, vor allem Schwere und Gruppierung

Problemstellung

Nur RPM

Wartung mit Werkzeugen (Paketverwaltung) von Dritten. Unsere Werkzeuge bieten zusätzliche Informationen bzw. Nutzbarkeit/Funktionalität, aber es gibt keinen Mangel an Vollständigkeit wenn reines 'rpm' genutzt wird.

Besonders der Wechsel zwischen 'reinem RPM' und SUSE-Werkzeugen wird explizit unterstützt. Die SUSE-Werkzeuge werden bessere (automatisierte) Funktionen bieten. Die Nutzung von Drittanbieterwerkzeugen kann zusätzliche manuelle Schritte erfordern (wie das Ausführen eines Skripts oder das Hinzufügen eines Paketdepots), um das System voll wartungsfähig zu halten.

Nur Aktualisierungen

Basierend auf den Anforderungen von 'Nur RPM' scheint der einfachste Ansatz zu sein, jede verfügbare Aktualisierung zu installieren. Dieses wähle die neuesten Pakete ist in der Tat der Weg, den die meisten paketbasierten Werkzeug gehen und wie auch rpm -F (freshen/auffrischen) umgestetzt ist.

Das Hauptproblem bei diesem Ansatz sind mögliche Probleme bei den Abhängigkeiten. Den typischen Fall bieten Kernel und Treiber, aber es trifft auch auf alle davon abhängigen Pakete zu. Stellen Sie sich einen installierten Kernel zusammen mit einem Kernel-Treiber von Drittanbietern vor. Wenn der Kernel-Hersteller eine Sicherheitsaktualisierung herausgeben muss, die die Treiber-ABI bricht, haben Sie besser den passenden Treiber zur Hand. Dies verlangt allerdings nach exakter zeitlicher Abstimmung. Sie können den Kernel nicht ohne den aktualisierten Treiber aktualisieren und andersherum.

Vermischen von Patches und Aktualisierungen

Patches bieten zusätzliche Informationen zu Aktualisierungen und gruppieren Aktualisierungen. Dies verbirgt Aktualisierungen effektiv vor der (Standard-) Ansicht des Nutzers und rückt den behobenen Fehler in der Vordergrund.
Beispiel:
Anstelle Aktualisierungen für bspw. glibc, glibc-locale, glibc-info, glibc-devel, glibc-i18ndata, glibc-32bit, glibc-locale-32bit und glibc-devel-32bit (typisch für ein 64-Bit-System bei dem die glibc aktualisiert wird) anzuzeigen, sieht man nur ein einzelnes Security fix for system library (glibc) an.

Dies ist schön, wenn für alle Aktualisierungen Patch-Informationen verfügbar sind. Allerdings ist dies bei Paketdepots von Drittanbietern nicht der Fall. Daher müssen auch reine Aktualisierungen (bei denen keine Patch-Informationen verfügbar sind) in die Ansicht mit eingebunden werden.

Das Konzept besteht darin, 'Imitat-Patches' mit einer normalen Priorität zu erstellen. Dies ist bisher nicht in openSUSE 11.0 umgesetzt.

Aktualisierungen auslösen

Die Existenz von 'Patches' und 'Paketen' wirft außerdem die Frage auf, 'was Aktualisierungen auslöst'?

Traditionell sind Patches die Auslöser für Aktualisierungen. Basierend auf verfügbaren Patches mit unerfüllten Abhängigkeiten, wählt die Anwendung (YaST, Zypper, PackageKit) die zu installierenden Aktualisierungen (Pakete!) aus.
Obwohl dies gut mit den meisten SUSE-Aktualisierungen funktioniert, berücksichtigt es keine Drittanbieteraktualisierungen (keine Patch-Informationen).

Dies ist auf Grund von Beschränkungen der internen Datenstruktur und Semantik in openSUSE 11.0 noch ungelöst. Wenn jemand Aktualisierungen installieren möchte, bietet zypper update -t package diese Funktion auf der Kommandozeile.

Patch-Level

Nach der Veröffentlichung der Distribution werden Probleme gelöst und Aktualisierungen werden veröffentlicht. Es gibt keine feste Aktualisierungsplanung, Aktualisierungen werden veröffentlicht wenn das Problem gelöst und die Lösung geteste und überprüft ist.

Dieser konstante Fluss von Aktualisierungen macht es schwer, einen Schnappschuss zu erstellen oder einen Systemstauts zu definieren. Man kann nur eine komplette Liste aller installierter Pakete ausgeben.

Manchmal ist es extrem nützlich einen bestimmten Stand wiederherzustellen. Gerade beim Einspielen einer zertifizierten Anwendung von Drittanbietern (gegen eine bestimmte Paketversion) ist dies zwingend.

Beginnend mit Code11 sollten Patch-Level zusammen mit der Funktionalität, ein System auf ein bestimmtes Patch-Level zu bringen und dort zu halen, möglich sein.

Konzept

Änderungen im Vergleich zu Code10

• Kein Auffrischen !
  • Der Bedarf nach einer Aktualisierung wird vom Paket festgestellt. Entweder durch
    • eine höhere Version (normale Aktualisierung)
    • Provides/Obsoletes (Umbenennungsaktualisierung)
    • Provides Name > Version (Herunterstufen, siehe die Fedora-Paketbaurichtlinien)
• Keine Atome !
  • Patch gruppiert die Pakete nur und bietet eine Beschreibung
  • Gruppen gelten pro Architektur
  • Anwendungsschicht filtert die Architektur, nicht der Solver
• Patches sind noarch
  • Patches sind generische 'Aktualisierungselemente'
  • normalerweise nicht an eine bestimmte Architektur gebunden
  • arch-spezifische Patches sind die Ausnahme, nicht die Regel

Nur RPMP

• Patches sind optional
  • kein Einfluss auf Wartung / Aktualisierungen
  • Patches sind hinzugefügte Werte, keine Kernwerte
  • einfach in autobuild zu erstellen
  • einfach vom Kundne zu erstellen!

• Patches sind nicht installiert
  • Aktualisierte Pakete sind installiert
  • Patches sind zufriedenstellend
  • (Ein Satz von ) aktualisierten Paketen passt zu einem Patch. Dies stellt den Patch zufrieden.

Nur Aktualisierungen

Die Lösung ist doppelt

1. wähle das beste Paket, nicht notwendigerweise das neueste.
2. aktualisiere nicht blind jedes Paket, sondern berechne einen funktionierenden Satz von Aktualisierungen.

Glücklicherweise bietet der Code11-Abhängigkeitenlöser diese Funktionalität.

Vermischen von Patches und Aktualisierungen

• Patches sind nicht auflösbar (haben keine Abhängigkeiten)
  • es besteht kein Bedarf
  • Patches sind reine Informationen, wenn Abhängigkeiten benötigt würden, müssten Sie von den Paketabhängigkeiten wiedergespiegelt werden

Aktualisierungen auslösen

• Patches lösen die Aktualisierung nicht aus, dass veranlassen Pakete
• Lässt den Abhängigkeitenauflöser einen möglichen Aktualisierungssatz berechnen (beste Aktualisierungen für das System)
• Passe Patch-Informationen auf diesen Satz an
• Pakete ohne passende Patch-Informationen erhalten einen 'normalen' Schweregrad

Patch-Level

• Patch-Level benötigen eine sequentielle Anordnung der Aktualisierungen
  • Ein Level muss eindeutig und unabhängig von verfügbaren Paketdepots sein
  • Sequenz kann nur pro Paketdepot festgestellt werden, wenn dies keine 100%ige Lösung ist

Offene Punkte

• Auslöser
  • openSUSE 11.0 nutzt immer noch Patches um Aktualisierungen auszulösen
  • standardmäßig werden nur Aktualisierungen mit Patch-Informationen installiert
  • nutzen Sie zypper up -t package um Aktualisierungen von Drittanbietern zu installieren
• Patch-Level-Erkennung
  • pro Paketdepot / Produkt
  • autobuild wird Zeitstempel erstellen (keine Level)
• Patch-Level-Sperrung
  • dies ist noch nicht implementiert