Re: Von Sarge zu Testing - und die Backports? mischen oder raus?
On 25.04.06 01:27:36, Matthias Haegele wrote:
> Andreas Pakulat schrieb:
> >On 25.04.06 00:41:41, Matthias Haegele wrote:
> >>Ace Dahlmann schrieb:
>
> [...]
> >>>Auf besagtem Sarge-Gerät sind ein paar Backports installiert. Sollte
> >>>man diese lieber runter schmeißen oder kann man ruhig Backports mit
> >>>Testing mischen?
>
> [...]
> >Hmm, es gibt diverse Gruende, einer waere z.B. das das nicht getestet
> >wurde und die Abhaengigkeiten nicht darauf ausgelegt sind. So koennte es
> >vorkommen das ein Backport ein bestimmtest Paket benoetigt, aber in den
> >Abhaengigkeiten keine versionierte Abhaengigkeit definiert wurde (weil
> >das nicht notwendig ist fuer Sarge). Diese bestimmte Paket hat aber
> >vllt. wesentliche Aenderungen erfahren die in der testing-Version
> >enthalten sind, dadurch koennte der Backport "kaputt" gehen, im Sinne
> >von nicht mehr richtig funktionieren.
> >Weiterhin gibts Probleme mit C++-Programmen, da gabs die "beruehmten"
> >ABI-Aenderungen, wodurch alle C++-Programme/Bibliotheken neu kompiliert
> >werden muessen. Hier sorgen korrekt definierte Abhaengigkeiten dafuer
> >das dann der Backport deinstalliert wird, ein Upgrade funktioniert da
> >nicht, da sich die Paketnamen der C++-Pakete geaendert haben (z.B. heist
> >libqt3c102-mt aus Sarge jetzt wieder libqt3-mt wie in Woody. Andere
> >Pakete heissen jetzt kdelibs4c2a... Es gibt sicher noch mehr, aber mir fallen
> >keine mehr ein. Ein Upgrade
> >sollte bei Backports von bpo, deren Version kleiner ist als die
> >Testing-Version vermutlich reibungslos klappen (da die dortigen
> >Backports eine recht gute Qualitaet haben), alle anderen Backports
> >wuerde ich zuerst auf die Sarge-Version downgraden.
>
> D.h. das "upgrade" von Backports nach Testing ist eher nicht zu empfehlen,
Das ist oftmals eher zu empfehlen als die Backports auf dem System zu
lassen (sofern das ueberhaupt moeglich ist).
> bzw.
> kann schiefgehen, da es kein "definierter Weg" ist,
Naja, generell sind Backports sowieso ein "undefinierter Weg", da nicht
von Debian offiziell unterstuetzt. Es kommt halt sehr stark auf die
Qualitaet der Backports an und wie "ordentlich" der Paketierer beim
Definieren der Abhaengigkeiten war.
> daher dann eher
> backport->sarge->testing, weil die Paketwerkzeuge teilweise zu "blöd" sind das
> richtig aufzulösen (vmtl. auch wg. den Versionsnummern der backports?).
Wie schon gesagt kann es verschiedene Gruende geben warum ein Upgrade
des Backports nicht funktioniert. Das hat nichts mit der "Unfaehigkeit"
der Pakettools zu tun, sondern mit der Natur von Backports und Testing
an sich. Es gilt naemlich: Testing =< Unstable bezogen auf die
Versionen. Aber Backports werden in den meisten Faellen aus
unstable-Paketen gebaut, damit ist die Versionsnummer aber auf jeden
Fall groesser als die aus Testing. Ob das nun zu einem fuer das
Paketmanagementsystem unloesbaren Problem wird oder nicht kommt eben auf
den Anwendungsfall an. Auch umbenannte Pakete (also in Testing anders
heissende) die als Backport mit hoeherer Version installiert sind
duerften zu Problemen fuehren.
Generell gibt es IIRC gar keinen supporteten Upgradeweg, es darf glaube
ich auch bei einem Upgrade vom reinen Sarge zu Testing etwas schief
gehen, besonders wenn Testing noch nicht eingefroren wurde. Aber es ist
sehr wahrscheinlich das das nicht passiert.
Andreas
--
Think twice before speaking, but don't say "think think click click".
Reply to: