Re: lohnt sich schon Etch (wegen OOo2)
Frank Küster wrote:
> Jou, der OP hat ohne nähere Angaben von Problemen berichtet. Wie kommst
> du darauf, dass diese Probleme an sarge liegen und in etch nicht mehr
> auftreten?
Ich habe lediglich davon berichtet, dass ich mit openoffice2 aus testing
keine derartigen Probleme kenne. Der ganze Java-Kram wurde ohne mein zutun
von apt zusammengestöpselt. Das beantwortet die Frage des OP, ob in etch
die Java-Geschichte problemlos läuft mit "ja" -- Nicht mehr und nicht
weniger. Insbesondere sagt es nichts darüber aus, ob es notwendigerweise
solche Probleme mit einem reinen sarge-sytem gibt.
>>>> Wirklich instabil ist eigentlich nur nur "unstable". Daher der Name ;-)
>> Der Name ist trotzdem Programm.
>
> Wieder so eine Aussage - hast du dafür auch Argumente?
Ja. Ich habe in den letzten Monaten mehrfach erlebt, dass Pakete aus sid in
aus dem einen oder andern Grund nicht einsatzbereit waren. Das reichte vom
nicht mehr funktionierenden Menü bis zum instantanen segfault nach Aufruf.
Mal stimmte eine Abbhängigkeit nicht, mal war ein Bug verbaut worden.
Wenn sowas vorkommt, dann nenne ich das "instabil".
> Wer in den
> letzten Wochen, eigentlich Monaten debian-devel-announce gelesen hat,
> der bekommt einen anderen Eindruck: Da wird explizit darum gebeten,
> "disruptive uploads" zu unterlassen und unstable immer möglichst
> funktionsfähig zu halten.
Die Absicht ist nicht identisch mit dem tatsächlichen Zustand. Ich meinte
selbstverständlich nicht, dass sid absichtlich instabil gemacht würde
(Warum sollte man?). Funktionsfähig ist im übrigen nicht dasselbe wie
stabil.
>> Es ist richtig, dass zwischendurch wegen
>> libc-Umstellung ein ganzer Haufen Pakete nachgezogen wurde. Aber das
>> waren bei weitem nicht alle
>
> Eben, ein Mischmasch.
Na und? Solange apt die Paket-Abhängigkeiten korrekt auflöst, kratzt es mich
genau gar nicht, ob alle Pakete aus dem gleichen Ast stammen.
> Es ist jedenfalls Glücksache und nichts, was man jemandem anderen ohne
> Erklärung empfehlen sollte - schon gar nicht wenn nach einem Rechner
Dafür schlägst Du vor mit Backports nicht-triviale etch-Funktionalität nach
sarge zu transplatieren. Das verschiebt das Glücksspiel auf den früher oder
später anstehenden Upgrade von sarge nach etch/stable.
> "für eine Freunding (DAU)" gefragt war. Zumal auch bei dieser
> Konstruktion das klassische testing-Problem auftritt, das mit den
> security-Updates.
Entweder Frau Dau hat ein reines Büro-System ohne Internet-Anbindung, oder
mit ISDN-Einwahl. Dann sind regelmäßige Security-Updates glatter Overkill.
Es handelt sich schließlich um ein Linux mit nur einem User-Account. Oder
es gibt eine mehr oder weniger dauerhafte Internet-Verbindung über Flatrate
oder ähnliches. Dann kann der OP von Zeit zu Zeit den Rechner über SSH aus
der Ferne administrieren, was die ganze Problematik des unbeaufsichtigten,
unadministrierten Betriebs entschärft. Um hier nicht mehr Risiko zu
schaffen als zu beseitigen, sollte dieser Zugang natürlich besonders gut
abgesichert sein.
---<(kaimartin)>---
--
Kai-Martin Knaak
http://lilalaser.de/blog
Reply to: