Das Paket bcachefs-tools wurde, wie bereits berichtet, mit der Aktualisierung auf Debian 12.7 als verwaist gekennzeichnet (orpahned). Es ist derzeit nur noch im Zweig experimental zu finden, falls es jemand übernehmen möchte. Debian hat das Paket in den vergangenen fünf Jahren angeboten, lange, bevor es mit Linux 6.7 im Januar in den Mainline-Kernel aufgenommen wurde.
Abhängigkeiten zu neu für Stable
Die Gründe, warum das Paket mit den Userspace-Tools für Bcachefs aus Debian Stable entfernt wurde, erläutert der Paketbetreuer und ehemalige Debian Projektleiter Jonathan Carter auf seinem Blog. Ausschlaggebend war, dass das die Utilities im Paket von C zu Rust umgeschrieben wurde und damit eine gänzlich andere Paketierung nötig wurde. Die Rust-Abhängigkeiten für bcachefs-tools in Debian stimmen überhaupt nicht mit den Build-Anforderungen überein. Carter erhielt vom Rust-Team den Tipp, es sei gängige Praxis, für das Bauen von Rust-Code in Debian, die Abhängigkeiten zu lockern.
Unmöglich zu betreuen
Carter hielt dies für eine bedenkliche Praxis und sieht bcachefs-tools damit für Debian Stable als nicht betreubar an. Auch wenn die Pakete mit gelockerten Abhängigkeiten funktionieren, denn außer Debian Stable hängt danach auch der LTS-Support oder die Unterstützung in Ubuntu hintendran. Der Upstream-Autor des Pakets ist gegen jede Lösung als die, die alle Abhängigkeiten streng mit den Tools ausliefert und besteht darauf, dass es nur mit diesen gebündelten Abhängigkeiten gebaut werden darf.
Wer derzeit Bcachefs in Debian Stable nutzen möchte, muss einen Kernel aus Backports verwenden, derzeit ist dort Linux 6.9 aktuell verfügbar. Die Werkzeuge für Bcachefs sind, wie bereits erwähnt, derzeit nur im Experimental-Zweig verfügbar. Ob sich ein neuer Betreuer für das Paket findet, wird sich zeigen.
Ich bin kein Meister im Paketebauen, deshalb die Nachfrage zum Verständnis: “Was bedeutet es die Abhängigkeiten zu lockern?”
Ich bin bisher immer davon ausgegangen, dass bestehende Abhängigkeiten eingehalten werden müssen damit code kompiliert werden kann.
Es ging in dem Fall um die Versionen der Abhängigkeiten. Der Upstream-Maintainer bestand auf den von ihm angegebenen Versionen, das konnte aber von Debian Stable nicht erfüllt werden.
Dankeschön. Jetzt kann ich etwas damit anfangen.
Bcachefs ist wohl gerade dabei die Schallmauer in der Entwicklung zu durchbrechen und eckt damit hier und da etwas an. Aber in Debian Sid dürfte das doch eigentlich kein prinzipielles Problem sein neue Versionen von abhängigen Paketen einzuspielen, während das bei Debian Stable gar nicht in Frage kommt.
Wenn die Version der bcachefs-tools in Debian Stable nicht patchbar sind, dann müssen Anwender die bcachefs austesten wollen halt nach Sid wechseln, was der Sache wohl auch angemessen sein dürfte.
Dazu muss halt die Manpower da sein. Die Updates zu betreuen.
Die Manpower ist da, das Paket wurde auch schon 5 Jahre erfolgreich betreut. Darum geht es gar nicht.
Es kollidiert aber mit den Erfordernissen die für Debian Stable Voraussetzung sind.
M.M.n. zieht Jonathan Carter hier die Konsequenzen jedoch etwas zu übertrieben.
Nur weil die Paketbeteung in Stable nicht möglich ist, weil auch für die dann fälligen Patches neue Abhängigkeiten eingebunden werden müssten, die es in Stable nicht geben darf,muss das Paket dann nicht auch gleich aus Sid entfernt werden.
Aber das Problem löst sich ohnehin von allein mit der Zeit. Momentan hat Bcachefs einen enormen Entwicklungsschub, aber in einiger Zeit, wenn das Fahrwasser etwas ruhiger geworden ist, ist es dann auch nicht mehr Nötig an allen Ecken von Bcachefs gleichzeitig zu schrauben und dann ist es auch wieder für Debian möglich ein Stable Paket über die Laufzeit einer Debianversion hinweg, korrekt zu betreuen.
Es ist war, dass es nicht (nur) ein Betreungsthema ist. Updates sollte es halt wirklich nur aus gutem Grund geben.
Und in der Landschaft der neueren Sprachen wird halt ständig irgendeine Library geupdated. Aber woher willst du denn wissen, dass das nicht irgendwas anderes bricht? Debian hat definitiv nicht die resourcen alles quer zu testen. Nicht mal die Linux Firmen tun das. Im Gegenteil, die versuchen die Codebasis alle klein zu dampfen.
Nur die Entwickler, die halt nie mal selbst das in der Produktion maintainen müssen, die scheissen da auf Admins und Anwender. Zumindest meiner Ansicht nach. Ich finde das von Debian schon ganz gut gehändelt.
Stabiles komplettes System, rest kann man in einem Container ja gerne fahren. Aber BASE mag ich gerne gut getestet und geprüft und nur wirklich notwendige Updates. Nicht weil irgendein Entwickler mal wieder eine Abhängigkeit für sein CVE geupdatet hat… (böse sarkastisch gesprochen…)
Nicht jede Software passt zu jeder Distro. Wenn bcachefs halt nicht in Stable kann, gehts halt nicht.
Ich verstehe die Aufregung garnicht. Wenn bcachefs in 10 Jahren Stable ist, kann es ja wieder rein.
Eigentlich ist das auch keine Aufregung, es handelt sich hier eher um Sorgsamkeit.
> Carter erhielt vom Rust-Team den Tipp, es sei gängige Praxis, für das Bauen von Rust-Code in Debian, die Abhängigkeiten zu lockern.
Da platzt das Märchen vom ach so stabilen und sauberen Debian. Vermutlich sind alle Pakete ranzig und pfeifen aus allen Löchern. Debian wird von Klebeband zusammengehalten.
bevor du nicht mal 5-10 jahre in deiner freizeit patches gebackported hast für umme für eine community die lieber drölftausend downstream distros baut, statt mal selbst zu paketieren, würde ich einfach mal den ball flachhalten.
Es ist stabil, weil man das ranzzeug, sich dauernd ändert nicht beim erstbesten zuruf nicht reinnimmt.
Glaubst du die rust leute werden die patches und issues backporten? die wollen sich ja noch nicht mal bei reproducible builds wirklich committen.
Ich kenne mich aus.
Na, wieder langweilig oder deprimiert😁.
Gibt mir Flashbacks an die Anfänge von btrfs, da gab es auch diverse Startschwierigkeiten