>Als stabil würde ich die Programmversionen nicht >bezeichnen. Das was die Paketersteller für stabil >halten, trifft es wohl eher.
Ich denke, das hat weniger mit den Paketerstellern zu tun, die nehmen in der Regel nur die Pakete von den jeweiligen Entwicklern, und bauen daraus ein Paket. Die Aufgabe der Paketbauer ist es nicht, dafür zu sorgen, dass das Programm vernünftig läuft, sondern nur, dass es mit der Distribution nicht in Konflikte gerät.
Für die Funktionstüchtigkeit eines Programmes sind eben die Entwickler zuständig, nicht die Paketierer.
>Und das man bei Problemen, nach einzelnen >Programmupdate, stets Systemupgrade zu hören >bekommt, hat mich aus der Community vertrieben. >Probleme löst man eben nicht mit pacman -Syu. Ohne >schnelle Leitung und Risikofreude ist das System >nicht zu ertragen.
Natürlich löst man nicht alle Probleme mit einem pacman -Syu, aber es ist oft eine solide Grundlage für die weitere Fehlersuche. Desweiteren hatte ich nicht das Gefühl, dass im deutschen Forum immer pacman -Syu als Allheilmittel gehandelt wird.
Die Aufgabe der Paketbauer ist es nicht, dafür zu sorgen, dass das Programm vernünftig läuft, sondern nur, dass es mit der Distribution nicht in Konflikte gerät.
Glücklicherweise gibt es Paketbauer, die das anders sehen. Pat Volkerding zum Beispiel.
Darum bin ich nach ein paar Wochen Arch wieder zu Slackware zurückgekehrt. Ist einfach angenehmer, wenn nicht alle paar Tage irgendwas nicht funktioniert.
> Die Aufgabe der Paketbauer ist es nicht, dafür zu sorgen, dass das Programm vernünftig läuft, sondern nur, dass es mit der Distribution nicht in Konflikte gerät.
Da hast du aber eine ganz komische Vorstellung über die Arbeit eines Paketmaintainers. Dessen Aufgabe ist es nämlich sehr wohl dafür zu sorgen das ein von im paketiertes Programm auch sauber funktioniert. Was meinst warum sich z.B. die Debian-Entwickler die Mühe machen Patches aus neueren Programmversionen auf eine ältere Version zurückzuportieren? Wohl kaum aus Spaß an der Freude.
Was nützt es, wenn der Maintainer kurz mal ein Paket zusammenbastelt, das zwar sauber kompiliert, sich fehlerfrei installieren lässt und auch die Distribution nicht beschädigt, dafür aber wegen eines Bugs nicht richtig funktioniert? Dann kann man das Paketieren auch gleich bleiben lassen.
Ein guter Maintainer steht in ständigem Kontakt mit dem/den Entwickler(n) seinen betreuten Pakets und/oder verfolgt ständig die Weiterentwicklung des Programm. Nur so können Bugs entdeckt und beseitigt werden, die im Zusammenspiel mit den verschiedenen Komponenten einer Distribution auftauchen (können).
> Für die Funktionstüchtigkeit eines Programmes sind eben die Entwickler zuständig, nicht die Paketierer.
Eben nicht nur. Oft ist es z.B. so das eine Version (sagen wir mal 2.11) einen Bug enthält und dieser erst offiziell mit der Version 2.12 gefixt wird. Nun kann sich eine Veröffentlichung solch einer Bugfix-Version schon mal ein Wochen hinziehen (Je nach Produktivität und Priorität des Entwicklers). Einen funktionierenden Patch für den Bug kann man als Paketmaintainer aber in der Regel problemlos per CVS/SVN/Git auf die ältere Version zurückportieren und so wenigstens für ein funktionierendes Paket sorgen, bevor die neue Version offiziell erscheint.
Die Versionsnummer habe ich nicht zufällig gewählt :
Der Intel-Grafiktreiber enthält in der Version 2.11 einen Bug, welcher auf allen 8xx-basierten Rechnern die Darstellung vieler Icons unter GNOME zerstört. Diese sind dann einfach nur weiß. Der Bug lässt sich relativ einfach beheben, indem man einen einzelnen Git-Commit aus der Version 2.11 wieder rauspatcht. Offiziell wird der Bug erst in der Version 2.12 beseitigt und diese erscheint frühesten Ende Juni.
Ich kann mich noch gut dran erinnern, als Bugs gefunden wurden, manchmal sicherheitsbetreffend, da landet schnell eine Beta-Version ins Repos. mit allen seinen Folgen. Generell waren die ersten Einspieler, die die von Problemen berichteten und die anderen konnten diese dann, so weit möglich, umschiffen.
Noch besser waren scheinbar kleine Updates, die dein System zerschossen haben. Auch nette Inkosistenzen bei den Paketnamen und deren Abhängigkeiten und tolle Sync Probleme auf unterschiedlichen Servern. Sehr beliebt waren/sind natürlich auch die Nvidia Treiber Updates.
So viel zu den Vorteilen von Bleeding Edge. Vielleicht merkt man mir an, ich bin kein Fan von B. E., mehr.
Ok, ich denke ich muss euren Ausführungen durchaus Recht geben: Ein Paketbauer sollte schon ein wenig mehr machen, und im Idealfall auch den Kontakt zu den Entwicklern Pflegen.
Sync-Probleme kamen bei mir selten vor, und waren nur dann nervtötend, wenn man genau in der Zeit hätte neue Programme installieren wollen (dessen Abhängigkeiten noch nicht alle verfügbar waren). Kam aber bisher selten genug vor, als dass ich damit leben kann.
Manchmal muss man bei updates einige config-Dateien anpassen, und dergleichen, aber updates, die mein System zerschießen, habe ich wie gesagt noch nie erlebt, und ich nutze Arch jetzt seit immerhin gut zwei Jahren auf verschiedenen Systemen.
Ich will nicht deine negativen Erfahrungen gegenüber Bleeding Edge in Frage stellen, ich habe lediglich noch keine ernsthaften Probleme damit erlebt.
Deren Existenz man dann schnell wieder vergisst und sich einige Wochen später über diese seltsame Datei wundert.. (Warum merkt es sich nicht einfach den md5 hash der Datei und überschreibt sie einfach, wenn dieser sich nicht von der default Version unterschiedet?)
Das Überschreiben von geänderten Konfigurationsdateien ist eine Katastrophe, von ungeänderten eine Glaubensfrage. Mit find(1) und diff(1) läßt sich das recht fix bewerkstelligen.
Nicht geänderte Konfigurationsdateien werden auch durch neue überschrieben. Einige Pakete haben einen kleinen Hinweistext, der nach der Installation ausgegeben wird. Außerdem gibt es pacdiffviewer, der einem die neuen Konfigurationsdateien raussucht und dann z.B. mit vimdiff vergleichen und zusammenführen lässt. Habe früher auch Gentoo benutzt, das war dagegen eine Katastrophe, Updates bei Arch funktionieren ziemlich geschmeidig. Und das ist ein wichtiger Punkt, dass man Updates gescheit durchführen kann. Ob ein System dabei nun ein Rolling Release oder ein halbjährliches hat, ist ziemlich Wurscht, Update bleibt Update. Und ich würde immer ein System vorziehen, welches sich gut aktualisieren lässt, dafür war früher Debian bekannt, Ubuntu geht sicher auch, aber mit Arch habe ich das gleiche mit einem System, welches aktuell ist und denoch ein "echtes" unixoides System ist.
>Als stabil würde ich die Programmversionen nicht
>bezeichnen. Das was die Paketersteller für stabil
>halten, trifft es wohl eher.
Ich denke, das hat weniger mit den Paketerstellern zu tun, die nehmen in der Regel nur die Pakete von den jeweiligen Entwicklern, und bauen daraus ein Paket.
Die Aufgabe der Paketbauer ist es nicht, dafür zu sorgen, dass das Programm vernünftig läuft, sondern nur, dass es mit der Distribution nicht in Konflikte gerät.
Für die Funktionstüchtigkeit eines Programmes sind eben die Entwickler zuständig, nicht die Paketierer.
>Und das man bei Problemen, nach einzelnen
>Programmupdate, stets Systemupgrade zu hören
>bekommt, hat mich aus der Community vertrieben.
>Probleme löst man eben nicht mit pacman -Syu. Ohne
>schnelle Leitung und Risikofreude ist das System
>nicht zu ertragen.
Natürlich löst man nicht alle Probleme mit einem pacman -Syu, aber es ist oft eine solide Grundlage für die weitere Fehlersuche. Desweiteren hatte ich nicht das Gefühl, dass im deutschen Forum immer pacman -Syu als Allheilmittel gehandelt wird.
Die Aufgabe der Paketbauer ist es nicht, dafür zu sorgen, dass das Programm vernünftig läuft, sondern nur, dass es mit der Distribution nicht in Konflikte gerät.
Glücklicherweise gibt es Paketbauer, die das anders sehen. Pat Volkerding zum Beispiel.
Darum bin ich nach ein paar Wochen Arch wieder zu Slackware zurückgekehrt. Ist einfach angenehmer, wenn nicht alle paar Tage irgendwas nicht funktioniert.
> Die Aufgabe der Paketbauer ist es nicht, dafür zu sorgen, dass das Programm vernünftig läuft, sondern nur, dass es mit der Distribution nicht in Konflikte gerät.
Da hast du aber eine ganz komische Vorstellung über die Arbeit eines Paketmaintainers. Dessen Aufgabe ist es nämlich sehr wohl dafür zu sorgen das ein von im paketiertes Programm auch sauber funktioniert. Was meinst warum sich z.B. die Debian-Entwickler die Mühe machen Patches aus neueren Programmversionen auf eine ältere Version zurückzuportieren? Wohl kaum aus Spaß an der Freude.
Was nützt es, wenn der Maintainer kurz mal ein Paket zusammenbastelt, das zwar sauber kompiliert, sich fehlerfrei installieren lässt und auch die Distribution nicht beschädigt, dafür aber wegen eines Bugs nicht richtig funktioniert? Dann kann man das Paketieren auch gleich bleiben lassen.
Ein guter Maintainer steht in ständigem Kontakt mit dem/den Entwickler(n) seinen betreuten Pakets und/oder verfolgt ständig die Weiterentwicklung des Programm. Nur so können Bugs entdeckt und beseitigt werden, die im Zusammenspiel mit den verschiedenen Komponenten einer Distribution auftauchen (können).
> Für die Funktionstüchtigkeit eines Programmes sind eben die Entwickler zuständig, nicht die Paketierer.
Eben nicht nur. Oft ist es z.B. so das eine Version (sagen wir mal 2.11) einen Bug enthält und dieser erst offiziell mit der Version 2.12 gefixt wird. Nun kann sich eine Veröffentlichung solch einer Bugfix-Version schon mal ein Wochen hinziehen (Je nach Produktivität und Priorität des Entwicklers). Einen funktionierenden Patch für den Bug kann man als Paketmaintainer aber in der Regel problemlos per CVS/SVN/Git auf die ältere Version zurückportieren und so wenigstens für ein funktionierendes Paket sorgen, bevor die neue Version offiziell erscheint.
Die Versionsnummer habe ich nicht zufällig gewählt :
Der Intel-Grafiktreiber enthält in der Version 2.11 einen Bug, welcher auf allen 8xx-basierten Rechnern die Darstellung vieler Icons unter GNOME zerstört. Diese sind dann einfach nur weiß. Der Bug lässt sich relativ einfach beheben, indem man einen einzelnen Git-Commit aus der Version 2.11 wieder rauspatcht. Offiziell wird der Bug erst in der Version 2.12 beseitigt und diese erscheint frühesten Ende Juni.
Ich kann mich noch gut dran erinnern, als Bugs gefunden wurden, manchmal sicherheitsbetreffend, da landet schnell eine Beta-Version ins Repos. mit allen seinen Folgen. Generell waren die ersten Einspieler, die die von Problemen berichteten und die anderen konnten diese dann, so weit möglich, umschiffen.
Noch besser waren scheinbar kleine Updates, die dein System zerschossen haben.
Auch nette Inkosistenzen bei den Paketnamen und deren Abhängigkeiten und tolle Sync Probleme auf unterschiedlichen Servern. Sehr beliebt waren/sind natürlich auch die Nvidia Treiber Updates.
So viel zu den Vorteilen von Bleeding Edge. Vielleicht merkt man mir an, ich bin kein Fan von B. E., mehr.
Ok, ich denke ich muss euren Ausführungen durchaus Recht geben: Ein Paketbauer sollte schon ein wenig mehr machen, und im Idealfall auch den Kontakt zu den Entwicklern Pflegen.
Sync-Probleme kamen bei mir selten vor, und waren nur dann nervtötend, wenn man genau in der Zeit hätte neue Programme installieren wollen (dessen Abhängigkeiten noch nicht alle verfügbar waren). Kam aber bisher selten genug vor, als dass ich damit leben kann.
Manchmal muss man bei updates einige config-Dateien anpassen, und dergleichen, aber updates, die mein System zerschießen, habe ich wie gesagt noch nie erlebt, und ich nutze Arch jetzt seit immerhin gut zwei Jahren auf verschiedenen Systemen.
Ich will nicht deine negativen Erfahrungen gegenüber Bleeding Edge in Frage stellen, ich habe lediglich noch keine ernsthaften Probleme damit erlebt.
Wie sieht das denn genau aus, wenn eine aktuellere Programmversion Dateien in /etc überschreiben möchte?
Dann wird die neuere Version der config als $dateiname.pacnew erstellt.
Deren Existenz man dann schnell wieder vergisst und sich einige Wochen später über diese seltsame Datei wundert..
(Warum merkt es sich nicht einfach den md5 hash der Datei und überschreibt sie einfach, wenn dieser sich nicht von der default Version unterschiedet?)
Das Überschreiben von geänderten Konfigurationsdateien ist eine Katastrophe, von ungeänderten eine Glaubensfrage.
Mit find(1) und diff(1) läßt sich das recht fix bewerkstelligen.
Nicht geänderte Konfigurationsdateien werden auch durch neue überschrieben. Einige Pakete haben einen kleinen Hinweistext, der nach der Installation ausgegeben wird. Außerdem gibt es pacdiffviewer, der einem die neuen Konfigurationsdateien raussucht und dann z.B. mit vimdiff vergleichen und zusammenführen lässt. Habe früher auch Gentoo benutzt, das war dagegen eine Katastrophe, Updates bei Arch funktionieren ziemlich geschmeidig. Und das ist ein wichtiger Punkt, dass man Updates gescheit durchführen kann. Ob ein System dabei nun ein Rolling Release oder ein halbjährliches hat, ist ziemlich Wurscht, Update bleibt Update. Und ich würde immer ein System vorziehen, welches sich gut aktualisieren lässt, dafür war früher Debian bekannt, Ubuntu geht sicher auch, aber mit Arch habe ich das gleiche mit einem System, welches aktuell ist und denoch ein "echtes" unixoides System ist.