Re: Merkwürdiges Problem mit Backports
Frank Küster schrieb:
Natürlich ist es testing. Wenn du Pakete aus stable willst, brauchst du
keine backports.
Hm, das klingt mehr also logisch ;)
Also gut, wir wollen auf einem sarge-System backports installieren.
Wenn man die von backports.org nimmt, dann sind das (mit Ausnahme von
security-fixes in besonderen Fällen, oder wenn backports nicht schnell
genug geupdated wird) immer die Versionen, die gerade in testing sind.
Bis vor kurzem gab's in testing 5.2.0-8, in sid aber 5.2.0-10. Offenbar
wurde ein update nötig, das nach testing sollte, aber 5.2.0-10 enthielt
zu große Veränderungen, als dass die release-manager das durchgelassen
hätten.
Also wurde ein Paket, das nur die für etch bestimmten Änderungen
enthält, nach testing-propose-updates hochgeladen und akzeptiert, jetzt
ist es in etch. Die Versionsnummer für testing-proposed-updates muss
kleiner sein als die in unstable und natürlich größer als die alte in
etch, und es muss eine sein, die es noch nicht gab (also nicht -9).
Es ist üblich und sinnvoll, das "extra für etch gemacht" auch in der
Versionsnummer zu speichern, daher wird von 5.2.0-8 auf 5.2.0-8+etch1
erhöht.
Auch das fängt jetzt an Sinn zu machen!
Ich verstehe was du meinst aber mir leuchtet es noch nicht ein. Und
ich möchte gerne verstehen wieso es so ist.
Alle Klarheiten beseitigt?
Dazu später mehr ;)
Oder ist meine Aussage, dass es eigentlich die selben Versionen sind
bereits eine Falschaussage?
Schauen wir uns das doch mal an:
http://packages.debian.org/cgi-bin/search_packages.pl?keywords=php5-common&searchon=names&subword=1&version=testing&release=all
(ich habe also nach php5-common in testing gesucht) gibt nur ein Paket,
draufklicken, runterscrollen und auf "Debian changelog" klicken:
[...]
Man sieht, dass da einige Änderungen im Vergleich zu 5.2.0-8 drin sind.
Die CVE-Nummern sind alles Sicherheitslücken, siehe
http://cve.mitre.org/cve/index.html.
Der Grund, warum 5.2.0-10 nicht nach etch konnte, sind wahrscheinlich
Bibliotheken: Wenn man php5 in unstable kompiliert, wo es
libfoo-dev_$sidversion mit neuen Features im Vergleich zur $etchversion
gibt, dann ist das Paket dann von libfoo (>= $sidversion) abhängig.
Wenn nun ausgeschlossen ist, dass libfoo noch nach etch wandert, kann
das in unstable kompilierte Paket nie nach etch kommen. Also muss man
es nach testing-proposed-updates hochladen und mit libfoo-dev aus
testing kompilieren.
Das ganze natürlich nur, wenn libfoo (im konkreten Fall ist es libgd2,
siehe http://bjorn.haxx.se/debian/testing.pl?package=php5) neue Features
hat, die eine Erhöhung der Version in den Depends-Zeilen bedingt.
Okay, alle Klarheiten beseitigt *g*
Der erste Teil deiner Mail ist einfach und logisch. Den zweiten Teil
muss ich mir noch mal in Ruhe anschauen, wenn ich wacher bin als jetzt.
Das Thema ist auf jeden Fall sehr interessant und auch wichtig. Von
daher hast du mir jetzt auch einen sehr schönen Ansatz geliefert, an dem
ich anfangen kann mich endlich mal näher mit den Paketzyklen zu
beschäftigen.
Gruß, Frank
Vielen Dank für diese wirklich sehr hilfreiche und interessanten Antworten!
Andy
Reply to: