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 -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
