OpenSUSE-Neuigkeiten/Ausblick auf openSUSE 11.0: Paketverwaltung, mit Duncan Mac-Vicar

aus openSUSE, der freien Wissensdatenbank

Freitag, 6. Juni 2008 von Francis Giannaros (Quelle )

In diesem Artikel werden wir all die Änderungen behandeln, die in und um den Paketverwaltungs-Stack im kommenden openSUSE 11.0 passiert sind. Es gab eine Fülle von Änderungen, sowohl visuell als auch hinter den Kulissen. Wir werden außerdem mit Duncan Mac-Vicar , dem YaST-Teamleiter, Zypp- und KDE-Entwickler sprechen, um später noch mehr über die Neuerungen zu erfahren.

Hinter den Kulissen

Neue Metadaten

Eine der Hauptänderungen, die zu der blitzschnellen Paketverwaltung von openSUSE 11.0 führt, sind die neuen jetzt für die Metadaten genutzten SOLV-Dateien. Während die klassischen RPM-MD (YUM) Metadaten im XML-Format zwar gut lesbar sind, führen sie dadurch aber zu signifikant größeren Dateien und es braucht länger als nötig, um sie zu verarbeiten. Das neue wörterbuchbasierte SOLV-Format für Paketdepots belegt nun 1/3 der Größe und kann fast augenblicklich geparst werden.

Neuer Abhängigkeitenauflöser

Der alte Solver hatte einige Probleme. Er war in manchen Fällen extrem langsam, es gab ein paar schlechte Entscheidungen beim Aufbau, und er bot schlechte Diagnosen und Vorschläge falls ein bestimmter Fall nicht auflösbar war.

Schneller

Der neue SAT Solver von Michael Schröder basiert auf der Annahme von Paketabhägigkeiten als Erfüllbarkeitsproblem der Aussagenlogik, was große Vorteile mit sich bringt, da diese Problematik sehr gut erforscht ist (es sind viele Beispiel-Solver verfügbar). Er ist dadurch unglaublich schnell und es bedarf keiner komplexen Algorithmen. Tatsächlich ist die Komplexität von Paketabhängigkeiten im Gegensatz zu anderen Bereichen, in denen SAT Solver genutzt werden, extrem gering.

Wenn Sie eine Demonstration der Geschwindigkeit sehen wollen, schauen Sie sich Duncans Videovergleich zwischen dem alten und neuen Zypper an.

Effizienter

Weiterhin führen die Änderungen mit den SOLV-Dateien und dem neuen Solver zu einer spürbar besseren Effizienz , besonders zu geringerem Arbeitsspeicherverbraucht im Vergleich zu Smart und YUM:

Intelligenter

Einer der gepriesenen Vorzüge des Smart Package Manager ist seine Fähigkeit, da wo APT und YUM versagen, intelligentere Entscheidungen zu treffen. Speziell ein paar Fälle wurden in Smarts README vorgeschlagen, bei denen sich Smart sehr gut verhält. Wie verhält sich also der neue ZYpp-Stack bei diesen Fällen? Er erledigt sie alle. (alle )

Eine der anderen praktischen Fähigkeiten des neuen Paketverwaltungs-Stack ist, dass er in Hardwareempfehlungen von Paketen mit einbezogen werden kann. Sie möchten, dass ihre Webcam funktioniert? Stecken Sie sie ein und führen Sie bspw. zypper up aus (oder nehmen Sie YaST) und es wird versuchen, alle Treiber aus den Online-Paketdepots herunterzuladen!

Interoperabilität

Patches und Schemata

Einer der größten Vorteile der openSUSE-Paketverwaltung ist die Verfügbarkeit von Patches und Schemata. Patches sind kleine Aktualisierungen um ein Problem zu lösen (und werden in den offiziellen Akutalisierungspaketdepots genutzt), und Schemata sind intelligente Gruppen von Paketen die empfohlen, benötigt und vorgeschlagen werden können, um bestimmte Funktionen verfügbar zu machen, ohne zu strikt bei den zu installierenden Paketen zu sein (wodurch die problematischere Matapaketlösung nicht benötigt wird).

Fedoras Aktualisierungsmetadaten nutzen ein yum-Plugin und eine updateinfo.xml-Beschreibung; Metadaten für die Verfügbarkeit von deltarpm werden über das yum-presto-Plugin verarbeitet. Die Paketverwaltung in openSUSE 11.0 liest auch Patches aus diesen Dateien! Das heißt, dass Sie den yum-Stack direkt nutzen können, und sie können Patches auch mit den bereits bestehenden Fedora-Werkzeugen erstellen. Des weiteren gibt Anstrengungen, ZYpp und YaST auf Fedora zu bauen.

PackageKit

PackageKit ist eine D-Bus-Abstraktionsschicht, die es dem Sitzungsnutzer erlaubt, Pakete sicher zu verwalten, indem sie eine über Distributions- und Architekturgrenzen hinweg verfügbare API bereit stellt. openSUSE 11.0 vollständig PackageKit-fähig; es können also alle Ursprungswerkzeuge über verschiedene Distributionen hinweg, die PackageKit nutzen, perfekt unter openSUSE eingesetzt werden.

Lesen Sie Duncans Blog-Eintrag um mehr darüber zu erfahren.

Neue Fähigkeiten

YaST

Die Qt- (KDE) und die GTK-Version (GNOME) haben verschiedene Änderungen erfahren, die besonders die jeweilige Paketverwaltungsschnittstelle verbessern. Die Integration von PackageKit bringt eine klarere Sicht auf alle Paketgruppen, die dank Symbolen schneller besser auseinander zu halten sind:

Die Ansicht der Schemata wurde ebenfalls verbessert:

Die GTK-Schnittstelle basiert nun auf einem komplett neuen, klaren Aufbau:

Die Depotverwaltung kann nun auch direkt aus der Paketverwaltung heraus aufgerufen werden. Gehen Sie einfach auf Installationsquellen -> Repositorium Verwalter. Das Modul Community/Gemeinschafts-Repositories wurde nun auch direkt in den Quellenverwalter integriert, so dass Sie beliebte Depots immer noch einfach aus einer Liste hinzufügen können.

Minianwendungen zur Aktualisierung

Die Integration mit PackageKit wurde verstärkt; GNOME unter openSUSE nutzt nun das PackageKit Updater Applet zur Handhabung aller offiziellen Aktualisierungen:

Die Minianwendung zur Aktualisierung unter KDE wurde auf KDE 4 portiert und hat ein optionales PackageKit-Backend erhalten.

Zypper

Neben der Tatsache, dass Zypper dank den bisher vorgestellten Änderungen an der Paketverwaltung signifikant schneller ist, hat es auch eine Menge neuer Funktionen erhalten, darunter:

Nahtlose Installation von entfernten und lokalen RPMs:

Unterstützung für Wildcards/Platzhalter:

Unter Zypper/Änderungen/11.0 finden Sie eine komplette Liste der Änderungen.

Gespräch mit Duncan Mac-Vicar

Was waren die größten Herausforderungen beim abermaligen Ändern der Hauptkomponenten der Paketverwaltung

Während openSUSE 10.3 investierten wir eine Menge Anstrengungen in die Restrukturierung der libzypp-API, so dass wir nun Dinge ändern konnten. Für 11.0 zahlte sich das aus. Wir haben an der API überhaupt nichts geändert! (nur etwas hinzugefügt, wie Sperren und anderes, um Zugriff auf den systemnahen Kram wie den SAT-namensraum zu bekommen). Die Herausforderung bestand also darin, die Klassen so anzupassen, dass sie sich wie ein dünner Wrapper über der SAT Solver-Bibliothek verhalten. Michael Andres und Stefan Schubert haben hier großartige Arbeit geleistet. Als das erst mal erledigt war, funktionierte so gut wie alles direkt aus der Box.

Ich würde sagen, die größten Hindernisse traten dort auf, wo Dinge geändert wurden, bei denen sich auch das Grundkonzept änderte, wie Produkte, Schemata und Patches nicht mehr zu installieren, sondern das SATisfied-Konzept zu nutzen. Dies zahlte sich als ein pures rpm-System aus, aber wir müssen die Details noch weiter reifen lassen.

Es gab außerdem eine Menge Arbeit für das SAT Solver-Team, dass diese schnelle und tolle C-Bibliothek erhielt. Das ZYpp-Team leistete hervorragende Arbeit, sie ohne große Änderungen zu integrieren, musste aber viele Fähigkeiten neu einbauen, um die vorher vorhandene Funktionalität zu erreichen.

Welche tollen Fähigkeiten wurden hinter den Kulissen sonst noch eingebaut?

Die Änderungen in PackageKit, die dazu führen, dass Sie jede PackageKit-Anwendung nutzen können, die dann automatisch ihre Paketverwaltung nutzt, ohne dass Sie einen Unterschied feststellen. Außerdem sind Delta-RPMs nun nicht länger an Patches gebunden, sie sind einfach nur noch zusätzliche Metadaten in einem Paketdepot, und libzypp kalkuliert dann, welchen Sie nutzen können. Das heißt, dass wir beispielsweise jederzeit damit beginnen können, Delta-RPMs für Factory-Aktualisierungen anzubieten. Das Format ist nebenbei auch noch kompatibel mit yum-presto.

Unsere Patch-Metadaten sind die gleichen wie die von yum genutzte updateinfo.xml, was die Build Service-Strategie, für mehrere Distributionen bauen zu können, unterstützt. Falls Delta-RPMs oder Aktualisierungsmetadaten jemals vom Build Service angeboten werden, dann sollte es keinen Unterschied machen, ob Sie Fedore oder openSUSE, yum oder zypper benutzen. Und auch wenn Sie eine firmeninterne Infrastruktur zur Erstellung ihrer eigenen Aktualisierungen haben, brauchen Sie keine zwei Varianten dieses Werkzeuges.

Wie sehen die Pläne für die Zukunft aus?

Zuerst einmal denke ich, dass wir uns nun auf der Straße befinden, die uns dort hinbringt, wo wir hin wollen. Pläne für die Zukunft enthalten Polierungen wie mehr PackageKit-Arbeit, das Aktivieren von Nutzerfähigkeiten wie Hardware-Empfehlungen in der Nutzerschnittstelle (diese Fähigkeiten sind schon seit Jahren da, aber nicht sehr sichtbar), Build Service-Integration, die Möglichkeit semantische Daten hinzuzufügen, usw.