Auf Grund der neuen Richtlinie des ubuntuusers Wikiteams zu PPAs möchte ich einfach mal ein Beispiel geben, wie leicht es sein kann durch ein PPA sein System in einen Zustand zu bringen, dass man nicht auf die neuste Version aktualisieren kann.
Als Beispiel nehme ich die KDE Fensterdekoration Aurorae. Sie ist für KDE 4.3 und es gibt noch keine Pakete für Jaunty. Es befindet sich in den Paketquellen für Karmic als kwin-style-aurorae und in Karmic+1 wird dieses Paket entfernt werden, da Aurorae Bestandteil von KWin in KDE 4.4 ist. Das ist wichtig im Verlaufe dieses Blogposts zu erinnern.
Angenommen ich hätte mit der Veroffentlichung von Aurorae auch ein Paket gebaut und in ein PPA gestellt. Zu dem Zeitpunkt hätte es noch kein Paket von Kubuntu gegeben und ich hätte mein Paket einfach mal aurorae genannt. Das Namensschema ist mir nicht bewusst. Ich hätte natürlich das PPA in den passenden Artikeln im ubuntuusers Wiki eingestellt. Ist ja nach den neuen Richtlinien abgedeckt, ich bin ja der Entwickler und weiß was ich tue.
Nun denke ich sollte das erste Problem schon erkennbar sein. Wenn ein Nutzer Karmic verwendet und die PPA Quelle freigeschaltet hat, dann hat er plötzlich zwei Pakete für die gleiche Software:
- aurorae
- kwin-style-aurorae
Diese Pakete enthalten exakt die gleiche Version und exakt die gleichen Dateien. Wenn man das Changelog mit den Maintainern entfernt, müsste – wenn ich korrekt gebaut habe – sogar die MD5 Summe übereinstimmen.
Mittlerweile existiert Karmic und ich biete die PPA Quelle nicht mehr an. Es befindet sich ja in den Paketquellen. Nun hab ich plötzlich einen schwerwiegenden Crash in der Dekoration festgestellt und behoben. Das ganze wird in trunk eingespielt und (weil wichtig) aktualisiere ich auch den tarball auf kde-look sowie informiere ich meine wichtigsten Downstreams (openSUSE und Kubuntu), damit sie neue Pakete bauen. An meine alte Paketquelle für Jaunty denke ich nicht mehr – ich bin unter Stress.
Das Problem dürfte recht erkennbar sein: wer das Paket aus den offiziellen Quellen installiert hat, bekommt automatisch das Update. Wer das Paket aus dem PPA hat, jedoch nicht. Bugs werden nicht mehr behoben.
Nun dreht sich das Rad der Zeit weiter. Weitere sechs Monate sind vergangen und das Upgrade auf Karmic+1 steht an. Aurorae wurde Ende Januar/Anfang Februar in KDE aufgenommen. Die Kubuntu Maintainer wissen das und passen ihre Abhängigkeiten entsprechend an. kwin-style-aurorae wird ein virtuelles Paket und kdebase-workspace hat die Abhängigkeiten so gesetzt, dass das Paket entfernt wurde. Ein Upgrade verursacht kein Problem. An Aurorae wurde seit dem ersten Paket jedoch kaum noch gearbeitet. Insbesondere heißen die Dateien noch gleich und werden an die gleichen Stellen wie zuvor installiert.
Nun gibt es immer noch User, die mein Paket aus der Zeit von Jaunty verwenden. Was wird passieren? Sie machen ihr Upgrade. Die Kubuntu Entwickler haben ihre Abhängigkeiten angepasst, von meinem komischen Paket was ich seit Monaten nicht mehr anbiete, wissen sie jedoch nichts oder denken nicht dran. kdebase-workspace wird also mein Paket nicht ersetzen. Nun wird das Upgrade durchgeführt. Irgendwann wird kdebase-workspace aktualisiert und schwups haben wir ein Problem. Das Paket enthält Dateien, die schon exisitieren! Nämlich die Dateien aus dem Paket aurorae. Das Upgrade schlägt fehl. kdebase-workspace ist nicht installiert. Der Anwender sieht den Fehler und installiert erst mal munter weiter. Passiert ja mal, dass ein Paket nicht funktioniert. Dann macht er den Neustart – wie aufgefordert. Er meldet sich an, der Splash Screen kommt, der Splash Screen geht und der Hintergrund ist schwarz. Aber warum? Nun ganz einfach: kdebase-workspace wurde nicht aktualisiert. Also kein Plasma, kein kwin – kein Desktop und kein Fenstermanager. Man kann auf dem System keine Anwendung aus der grafischen Oberfläche starten. Man kann keinen Browser aufmachen um im Forum nachzufragen wie das Problem behoben werden kann. Man hat für den Normalanwender ein zuerstörtes System.
Ich hoffe ich konnte mit diesem kleinen Beispiel ganz gut aufzeigen warum PPAs und Fremdquellen im Allgemeinen ein riesiges Problem beim Update darstellen können. Wer sicher sein will, nimmt entweder keine PPAs oder nur die von den Maintainern, da diese ihre Abhängigkeiten anpassen.
Danke für die ausführliche Darstellung. Ich hatte das zwar schon nach der Ikhaya-Meldung für gut befunden, aber vielleicht hilft es ja was. 😉
Also so einfach wie du eingangs ankündigst ist ja dann doch nicht, wie die Länge verdeutlicht. Wenn kde-workspace nicht aktualisiert werden kann, zieht sich das die Abhängigkeitsschlaufe hoch und ein Großteil der Aktualisierungen wird scheitern. Wer dann einfach lustig neu startet, sollte sich auch nicht wundern. Sicher ist es ein Problem, das man dann erstmal lösen muss, weil es der PM alleine nicht kann, aber keins was überraschend aufschlägt.
Mein Tipp wäre, vor so einem großen Upgrade PPA Quellen rausnehmen und dann die orphans, Pakete ohne Referenz, löschen. Um weiter die Abhängigkeiten zu befriedigen bleibt dem PM gar nichts anderes übrig, als auf den getesteten Upgradepfad zurück zu kehren.
aptitude purge ‘~o’
aptitude full-upgrade
@adun: jup, hast Recht ich hab es hier extra absichtlich schlimmer dargestellt, als es tatsächlich wäre. Wollte einfach den worst-case aufzeigen.
Bei einem dist-upgrade werden doch normalerweise alle lokal installierten Pakete runtergeschmissen. Könnte man das nicht auch mit ppa-Quellen machen, bzw. werden die nicht deaktiviert und ebenfalls automatisch entfernt.
@Matthias: mir wäre neu, dass lokal installierte Pakete entfernt werden. Zumindest bei mir wurden noch nie Fremdpakete (e.g. Opera/Sype) entfernt.
Deine Bedenken hinsichtlich PPAs sind natürlich berechtigt. Deswegen ist es auch sinnvoll, die User aufzuklären. Und PPAs können ein Upgrade – wenn sie es nicht zerstören – komplizierter machen, weil man eben darauf achten muss, welche Pakete man zunächst runterschmeißt.
Auf der anderen Seite bieten die PPAs aber auch eine gute Möglichkeit, Pakete anzubieten, die nicht in den Paketquellen der Distributoren enthalten sind. So eine Art Staging-Bereich für Endnutzeranwendungen. Wenn ein neues Programm erscheint, kann man ja nicht immer ein halbes Jahr (im günstigsten Falle) warten, bis man sich dieses Programm installiert.
Und ich würde eben auch nicht Usern empfehlen, sich Programme statt aus PPAs aus den Quellen zu installieren. Denn dann habe ich u.U. noch viel größere Probleme: Viele Installationsmethoden bieten kein »make uninstall«, das heißt, die Dateien lassen sich nicht so leicht wieder aus dem System entfernen. Und dann werden sie in der Regel nach /usr/local installiert. Dort aber liegen sie dann, ewig unaktualisiert, und die sauber installierten Dateien aus einem später erschienenen Paket werden nicht einmal angerührt (schließlich liegt /usr/local im PATH vor /usr). Und im Gegensatz zu den konfligierenden Paketen bekomme ich nicht einmal eine Warnmeldung.
Also, mein Votum: PPAs ja, aber mit Augenmaß und Bewusstsein für die möglichen Konsequenzen.