Re: lohnt sich schon Etch (wegen OOo2)
kai-martin knaak <kmk@familieknaak.de> wrote:
> 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.
Die Frage war aber nicht, ob es in etch Probleme gibt, sondern ob es in
etch "besser" läuft als in sarge. Du hast also die falsche Frage
richtig beantwortet - Null Punkte.
>>>>> 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?
>
[...]
> 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.
Das ist völlig klar, aber wenn du sagst "Der Name [unstable] ist
Programm", dann interpretiere ich das als "Instabilität ist Absicht".
Was soll es denn stattdessen heissen? Oder ruderst du nur zurück?
> Ich meinte
> selbstverständlich nicht, dass sid absichtlich instabil gemacht würde
> (Warum sollte man?).
Man könnte auch die Strategie fahren, in unstable möglichst überall
bleeding-edge-Software zu haben, ohne Rücksicht auf Stabilität. Ein
release käme dann nur zustande, wenn die Migration nach testing nicht
automatisiert verläuft und auch Uploads direkt nach testing möglich
sind. Aber denkbar wäre es; ich habe deine Aussage "Der Name ist
Programm" so verstanden, als hättest du den Debian-Release-Prozess
derart missverstanden.
>>> 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.
Jo, und wenn was nicht klappt schreibst du das den Paketen aus sid zu,
weil da unstable drauf steht. In einem Mischsystem aus sarge, etch und
sid. Oder wie?
Ich fürchte, du schwafelst.
>> 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 klingt jetzt ganz furchterregend. Aber Mischsysteme findest du
total simpel und problemlos. Ja was denn jetzt? Dabei machen sich bei
backports Leute richtig Arbeit, um die "Transplantation" zu optimieren
und zu testen, während das Mischsystem ein ungetestes Zufallsprodukt
ist.
> Das verschiebt das Glücksspiel auf den früher oder
> später anstehenden Upgrade von sarge nach etch/stable.
Du schwafelst schon wieder. Welche Fakten rechtfertigen deiner Meinung
nach die Befürchtung, es könne beim Upgrade von sarge+backports nach
etch/stable besondere Probleme geben? Die nicht auch bei reinem sarge
auftreten?
>> "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.
Wie bitte? Sei doch bitte so nett und antworte mit so einer Einstellung
einfach gar nicht mehr auf Postings mit Anfänger-Bezug. Natürlich gibt
es dutzendweise security-Updates, die für Bürorechner irrelevant sind.
Aber das muss man erst mal beurteilen können. Ich traue mir das nur
begrenzt zu, jedenfalls wenn ich nicht mehr Zeit investiere als das
Debian-Security-Advisory zu lesen, einer "DAU" möchte ich das nicht
zumuten.
> 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.
Ach so, du rätst Leuten zu einem Vorgehen, bei dem sie sich dann einen
Nebenjob als Supporter einkaufen? Das solltest du aber dick
dazuschreiben. Heino hat jedenfalls nichts davon geschrieben, wieviel
Zeit er langfristig da reinstecken möchte.
Gruß, Frank
--
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)
Reply to: