Re: Woody -> Sarge?
On Wed, Aug 07, 2002 at 10:49:12PM +0200, Rainer Ellinger wrote:
> Dirk Prösdorf schrieb:
> > Weshalb mir daran gelegen wäre, dass bekannte Fehler auch im Stable
> > beseitigt werden.
>
> Werden sie ja. Abonniere debian-security-announce und setze in die
> sources.list die security.debian.org Server. Gerade kommen da wieder
> täglich Updates.
Also, debian-security-announce habe ich im Abo, genauso wie bugtraq, da
manchmal der kleine zeitliche Unterschied darüber entscheidet, ob ein
Server fällt oder nicht. Aber es geht nicht um Security-Updates, sondern
Bugfixes.
Mal ein Beispiel aus meinen knapp drei Wochen Debian-Erfahrung:
Ich stelle auf meinem Testsystem fest, dass der INN bei jedem
nächtlichen Logrotate seine alten Logfiles vernichtet. Das ist enorm
ägerlich und kann die Sicherheit betreffen, muss es aber nicht. Nach
etwas suchen ist auch der Fehler gefunden. Der Maintainer hatte, um
andere Probleme einzelner User zu beseitigen, diesen Bug eingebaut (ging
hier über die Liste).
Die defekte Software ist immer noch Bestandteil von Stable, da halt,
m.E. zu recht, kein Sekurity-Update. Ich behelf mir damit, dass ich für
den nächsten Server mir eine gepatchte Version des INN baue. Der nächste
User, der aber diese Software einsetzt und nicht erst alle Bugreports
durchliest (was ich auch nicht für *alle* Pakete gemacht habe) wird
dieses Problem auch haben.
Nun kann man sich auf den Standpunkt stellen, dass halt zu jedem Paket,
das eingesetzt werden soll, die Bugreports durchgelesen werden sollten.
Ich hatte aber die Intention, dass auch im Stable gepatch werden kann,
d.h. das Stable ist etwas dynamischer ('ewiges Stable') und es gibt
zusätzliche Branchs für die jeweiligen Patch-Releases. Aber über das
'Wie' kann man wirklich streiten, für mich ist die Frage eher relevant,
ob 'Stable' in solchen Fällen gebugfixt wird und wenn es nur darum geht,
den einen Bugfix wieder raus zu nehmen und in's nächste Unstable zu
stellen.
M.E. ist hier eine Abwägung notwendig, was mehr Schaden anrichtet, ein
Update im Stable, mit den möglichen Problemen, die ja mittels Test
minimiert werden können, oder der Einsatz der kaputten Software.
> Aber auch dabei muss man sich wieder dem Grundsatzproblem stellen, mit
> einem korrigierten Fehler nicht zwei neue einzuführen.
Klar, das Problem kenne ich nicht nur aus dem obrigen Beispiel, sondern
es ist inhärent jeglicher komplexeren Software.
> Insofern
> konzentrieren sich die Korrekturen nur auf Sicherheitsprobleme. Womit
> man aber in der Praxis alle ernsthaften Probleme meist mit erfasst hat.
M.E. eben nicht.
> Ich mag diese Zyklus-Diskussion nicht sonderlich, weil sie von
> wichtigeren Punkten und Diskussionen ablenkt. testing/unstable sind im
> Vergleich zu anderen Distris dermassen aktuell, dass im Grunde Debian
> genauso als die aktuelleste Distribution berühmt werden könnte. Andere
> verkaufen sowas sogar in Schachteln ;-)
Klar, für mein 'Spielsystem' bevorzuge ich auch Testing und das, was Du
anführst war sicherlich einer der Gründe (neben dem Paketmanagment) es
mal mit Debian zu probieren. Besonders, da das alte System nicht mehr
vom Distributor unterstützt wurde und ein Update eh eine Neuinstallation
bedeutet hätte.
> Eine viel wichtigere Entwicklung wäre, Debian ins besondere als das
> perfekte Desktop-System zu sehen.
*Grrr*, da habe ich mich noch gar nicht dran getraut (Faktor Zeit). ;-)
> > Mit dem Problem, dass auch alle bekannten Fehler der eigentlichen
> > Software und der Debianimplementierung 'stabil' bleiben.
>
> Jein. Eine ganz schwierige Abwägung, durch Korrekturen nicht neue
> Probleme einzuführen. Nicht umsonst finden sich bei den meist genutzten
> Basis-Paketen die längsten Bug-Listen im BTS, weil Korrekturen auch mit
> sehr viel Umsicht durchgeführt werden müssen.
Klar und dann gehen sie doch daneben. ;-)
> Aber solche Pakete kann man problemlos
> aus unstable ziehen, weil Sie sehr alleinstehend sind. Als Anwender von
> user-mode-linux weiss man das.
Wobei es genauso möglich wäre, diese 'relativ alleinstehenden' Pakete
separat in's Stable zu migirieren, wenn dadurch Fehler beseitigt werden.
> > Beim Kernel werden aber bekannte Fehler auch in Subleveln beseitigt
> > und nicht bis zum nächsten Stable-Patchlevel gewartet.
>
> Immer eine Frage der Perspektive: Kernel 2.2 = stable, 2.4 = testing,
> 2.5 = unstable ;-))
Mh, so handhabe ich es auch. ;-)
Reply to: