Hallo Bernhard, Am Die, den 06.01.2004 schrieb Bernhard Walle um 00:08:
Aber die Behauptung, dass man für neue Programme eine aktuelle glibc braucht, ist schlicht und einfach Unfug. Das mag für Binärpakete gelten (wobei vernünftige Pakete nur glibc 2.2 voraussetzen), gibt aber nicht für Quellpakete.
Ich habe mich da von Thomas B. schon berichtigen lassen. Aber wenn ich auf einem SuSE 8.2 System durch den Mangel an RPM Paketen aktueller Software auf die Quellen angewiesen bin und das schon nach dem "./configure" scheitert, dann ist mir das als Endbenutzer egal, ob die fehlende Abhängigkeit nun die glibc oder nicht war. Bei kmess habe ich festgestellt: "Aha. Das funzt nicht. In der letzten Zeile steht irgendwas von glibc... Schuldiger gefunden. Andere Möglichkeit der Installation muss her." Für mich ist das Auflösen von configure Fehlern zu anstrengend und nervtötend. DAFÜR habe ich keine Zeit. Weil das nämlich mich beschäftigt und nicht die CPU.
Wenn ein MSN-Client auf glibc-Interna zugreifen würde, dann hätte der Programmierer ganz schön viel falsch gemacht. Das Programm würde ich garantiert nicht installieren. Sowas kann man portabel mit Qt und KDE alleine realisieren. PSI setzt im Grunde nur Qt voraus, läuft auch unter Windows und MacOS und die glibc-Version ist zum Kompilieren der Quellen herzlich egal.
Für sachliche Argumente, warum meine Meinung zu dem configure Output falsch ist, bin ich dankbar, weil ich nicht die Bohne von make und diesem ganzen gcc Kram im Detail durchblicke und es interessiert mich auch frank und frei nicht die Bohne. Wenn ich Software nicht mit einfachen Schritten installieren kann, dann ist sie für mich nicht-existent.
Ehrlich gesagt hätte ich ein verdammt ungutes Gefühl, dass plötzlich Probleme auftauchen, die ich im Moment gar nicht brauchen kann.
Die unstable Quellen neuer Software sind im Portage Baum maskiert und tauchen nur auf, wenn man sie sucht. Wenn die Entwickler einer Software sagen, ihr Produkt sei als produktiv oder stable zu betrachten, dann ist die Wahrscheinlichkeit sehr groß, dass diese Software im Portage Tree landet, nachdem sie getestet wurde. Gnome 2.4 ist im Portage Tree, ebenso Gnome 2.5, allerdings ist Gnome 2.5 maskiert. Ein Update wird also nicht Gnome 2.4 durch eine unausgereifte Version ersetzen. Blender 2.28 ist aktuell im Portage Tree, aber auch das maskierte Blender 2.31a lässt sich installieren. Man hat immer die Wahl.
Gibt es Security-Updates bei Gentoo einzeln ohne dass man das halbe System aktualisiert? Wahrscheinlich nicht.
Doch. Die aktuellen Gentoo Sources des Kernels sind beispielsweise 2.4.22 abwärts. Der Kernel und andere Pakete werden gepatcht. Wer neuere Quellen will, kann sich die Vanilla Quellen über Portage ziehen. Wenn eine neue Version einer Software eine Sicherheitslücke behebt, dann sehe ich keinen Grund, warum nicht gleich eine neue Version installiert wird, anstelle die alte nur zu patchen (neu übersetzt wird ohnehin). Beim letzten rsync Exploit oder der letzten OpenSSH Version war das so. Bei CVS kann ich mich auch daran erinnern.
Bei SuSE oder auch Debian stable(wobei mir letztes für den Desktop zu alt ist) kann ich mich einigermaßen darauf verlassen, dass mir ein Security Update nicht das System zerschießt.
Das ist mir bei Gentoo auch noch nie passiert. Es landet ja auch eigentlich nur Software in Portage, die durch die Autoren der Software als stable gekennzeichnet ist und durch Gentoo Portage Maintainer getestet wurde. Schließlich muss nicht nur getestet werden wie die fertige Software läuft, sondern auch der Build Prozess muss getestet werden. Grüße, Tobias