In Debians Paketverwaltungssystem gibt es für die x86_64-Architektur mehr als 74k Pakete. Dass nicht alle davon optimal betreut werden, sollte jedem klar sein, vor allem bei einer Distribution, die von freiwilligen Maintainern getragen wird.
Aggressiver entfernen
Seit rund zwei Wochen wird bei Debian diskutiert, ob und wenn ja, wie nicht betreute Pakete künftig aus dem Unstable-Zweig der Distribution entfernt werden sollen. Angestoßen wurde die Diskussion vom seit 2013 als Entwickler tätigen Helmut Grohne, der sich für ein aggressiveres Vorgehen beim Entfernen von Paketen ausspricht. Er beginnt die Diskussion deshalb auch passend mit dem Satz »please allow me to open a can of worms«.
Can of Worms
Es ist schwierig, den richtigen Zeitpunkt für die Entfernung eines lange unbetreuten Pakets zu finden. Vielleicht hat das Paket ja trotzdem noch Anwender oder die Entfernung hat aufgrund von Abhängigkeiten Auswirkungen auf andere Pakete. Im Rahmen der QA-Arbeit verschiedener Teams werden ständig veraltete unbetreute Pakete entdeckt, die sich nicht mehr bauen lassen, Fehler enthalten oder sonstige Auffälligkeiten zeigen. Dabei stellt sich dann die Frage, wie viel Aufwand es bedeutet, solche Pakete wieder auf den neuesten Stand zu bringen und ob sich ein neuer Maintainer finden lässt.
Weniger ist mehr
Grohne ist überzeugt, dass zu viele solcher Pakete in Unstable verbleiben und dort Kosten in Form von Entwicklerzeit verursachen und tritt für ein aggressiveres Entfernen ein. Niels Thykier vom Release Team pflichtet ihm bei und bevorzugt einen Automatismus oder zum Anfang zumindest einen semi-automatischen Prozess, um hier keine wertvollen menschlichen Ressourcen im Entfernungsprozess zu binden. Hier könnte ein modifiziertes Script aus der UDD einen Einstieg bieten, mit dem das Release Team automatisch zu entfernende Pakete mit RC-Bugs in Testing identifiziert. Andere Entwickler sehen keinen Handlungsbedarf. Charles Plessy hält es für bedenklich, dass es viel einfacher ist, ein Paket im Atrchiv verrotten zu lassen, als es zu entfernen.
Im aktuellen Bits from the DPL für September bezieht Projektleiter Andreas Tille Stellung zu dieser Diskussion:
Ich würde mich freuen, wenn diese Diskussion zu aggressiveren Entfernungen führen würde, auf die wir uns einigen können, unabhängig davon, ob sie automatisiert, halbautomatisiert oder von einer Person durchgeführt werden, die eine automatisch erstellte Liste bearbeitet (unterstützt durch ein objektives Verfahren). Um eine Analogie zu verwenden: Ich habe festgestellt, dass sich jede Bildersammlung durch aggressives Beschneiden verbessert. In ähnlicher Weise bin ich überzeugt, dass Debian sich verbessern wird, wenn wir Pakete entfernen, die unseren Nutzern nicht mehr gut dienen.
Bleibt abzuwarten, ob diese Diskussion Früchte trägt und zu einer kohärenten Paketbasis in Unstable führt.
Es gibt ein “Packdatum” von jedem Paket. Ich meine einmal bei KaOs gelesen zu haben, dass dort jedes Paket mindestens einmal im Jahr neu erstellt werden muss, ansonsten fliegt es aus den Repositorien.
Wenn Debian seinen “Rumpelkeller” jetzt einmal aufräumen möchte, müsste man einfach mal die ältesten Päckchen zur Erneuerung aufrufen.
Wenn dann nichts geschieht und sich nach einer Latenz immer noch niemand um das Paket kümmern möchte, dann kann das Paket auch entfernt werden.
Das wäre jedenfalls mein Vorschlag zur Vorgehensweise.
Es verwundert mich, dass es bei Debian dazu noch keine Regel gibt.
Es fehlt ein Link zur “Diskussion” bzw. dem Start dieser durch Helmut Grohne.
Ups, nachgereicht.
Das ist ein allgemeines Problem bei den üblichen Linuxdistros.
Es gibt ja, bis auf wenige Ausnahmen, nur Debian GNU/Linux und Arch. Der Großteil weiterer Distros basiert auf einer der beiden und “betreut” Pakete gar nicht wirklich in der Form wie es Debian/Arch tut.
Es ist ein hochrelevantes Thema, weil es die erbenden Distros stark beeinflusst.
Arch geht definitiv den aggressiveren Weg und ich schließe mich dem an.
Sogar beim AUR sind die sehr schnell wenn da was gemeldet wird. Und ich persönlich finde das einfach voll ok.
Es ist deren Infrastruktur und hat im Regelfall einen positiven Einfluss auf die Qualität.
Arch ist im Prinzip eine Sammlung von PKGBUILD’s.
Ist so eine Bauanleitung einmal erstellt, dann besteht die Arbeit des Maintainers im günstigsten Fall ledig darin, die E-Mail zu lesen die von Git verschickt wird, wenn eine neue Programmversion herauskommt und danach muss er im jeweiligen PKGBUILD nur noch die Versionsnummer entsprechend anheben und ‘updpkgsums‘ gefolgt von ‘makepkg -fi’ eingeben.
Natürlich gehört auch noch ein wenig mehr dazu,wie z.B. testen. Aber “das Wunder von Arch” besteht darin, einfache Dinge möglichst einfach zu handhaben.