Umgang mit backports

[guennid]

Ich verwende diese Quelle gezielt, d.h. nur im Einzelfall. Nun bin ich gerade dabei, ein dist-upgrade auf einer Maschine zu fahren und überlege, wie ich das einschließlich der installierten backports-Pakete am vollständigsten, aber am wenigsten riskant erreiche. Automatische System-Upgrades interessieren mich nicht.

Ein

Code: Alles auswählen

apt-get -t stretch-backports -s upgrade

erbrachte keinen Unterschied zu einem

Code: Alles auswählen

apt-get -t stretch-backports -s dist-upgrade

, aber das mag Zufall gewesen sein. Meine Frage also: Ist - backports betreffend - ein einfaches upgrade einem dist-upgrade vorzuziehen? Ist der Ansatz an sich schon falsch?

Und nochmal: Ich fahre keine automatisierten upgrades, werde mich also - nicht zuletzt angesichts der hier geführten Diskussionen - nicht mit pinning beschäftigen.

[KBDCALLS]

Irgendwie hab ich so das Gefühl du hast von den Backports nichts verstanden. Die werden nur bei einem dist-upgrade / full-upgrade berücksichtigt wenn schon installiert. Denn die haben ja von sich aus ne Priority von 1. Da braucht man garnichts rumbasteln

[guennid]

Für mich ist Wissen keine Frage von 0 oder 1.

Da die Backports-Paketquelle standardmäßig deaktiviert ist, werden installierte Backports auch nicht automatisch aktualisiert.

Aber vielleicht kannst du ja mein Wissen dahingehend erweitern, was in dieser "Beschreibung" unter "standardmäßig deaktiviert" und "automatisch aktualisiert" zu verstehen ist.

Nach meiner Erfahrung wurden hier backports-Pakete beim dist-upgrade eines gegebenen Systems nie berücksichtigt. Und das Beispiel zeigt das ebenfalls. Anders verstehe ich zur Zeit in der Tat nicht, inwiefern da nach einem

Code: Alles auswählen

apt-get dist-upgrade

beim unmittlebar folgenden

Code: Alles auswählen

apt-get -t stretch-backports -s upgrade

noch weitere Pakete aus den backports gezogen werden sollten.

[KBDCALLS]

Es ist aber schon nicht ganz unwichtig zu verstehen , Warum die Backports nicht automatisch installiert werden .
Da liegt daran das sie eine Priority von 1 haben. Was durch die Release Datei geregelt wird. Denn normal wäre 500 .

Nehmen wir mal an es gäbe ein Paket Hutzliputzli in Stable in der Version 1 und in den Backports in der Version 2.
Dann würde bei einem apt-get install . Das Paket von Stable installiert, obwohl eine kleinere Version, es hat ja die hörere Priorität von 500 . Selbst bei einem dist-upgrade wurde nur eine neuere Version installiert , wenn sie in Stable vorliegt. Will ich die Version aus den Backports haben, dann muss die explizit installieren. Also apt-get install - t stable-backports paket oder apt-get install paket/stable-backports Und jetzt wird das auch bei einem dist-upgrade beachtet. Trudelt in den Backports jetzt eine neuere Version ein, dann wird die installiert.

Gibts das Paket nur in den Backports und ich will das installieren, dann reicht ein apt-get install paket aus.

• file:///usr/share/doc/debian-handbook/html/de-DE/sect.apt-get.html#sect.apt.priorities

[MSfree]

Nehmen wir mal an es gäbe ein Paket Hutzliputzli in Stable in der Version 1 und in den Backports in der Version 2.

Machen wie es mal konkreter:

In Jessie gibt es Hutzliputzli in Version 1
In Jessie-Backports gibt es Hutzliputzli in Version 2
In Stretch gibt es Hutzliputzli in Version 3

1. Was passiert bei einem dist-upgrade von Jessie mach Stretch, wenn ich unter Jessie Hutzliputzli aus den Jessie-Backports installiert hatte?

Wenn es in Stretch-Backports Hutzliputzli in Version 4 gäbe,

2. Was passiert bei einem dist-upgrade von Jessie mach Stretch, wenn ich unter Jessie Hutzliputzli aus den Jessie-Backports installiert hatte?

[KBDCALLS]

Die Backports sollte man entfernen , bevor von einer Debianversion zur nächsten per dist-upgrade / full-upgrade updadet. Also von 8 auf 9 zum Beispiel. Die Packetversionen in den Backports haben einen angehängtes ~bpo , sind dadurch kleiner auch wenn in der nächsten Debianversion ansonten die gleiche Paketversion vohanden ist. Also 2~bpo wäre kleiner als 2. Die Backport Version würde also ersetzt. Geht in der Regel auch so , aber der Teufel steckt manchmal drin, wenn die Backports nicht entfernt werden.

[NAB]

guennid, vielleicht solltest du mal klarstellen, was du mit "ein dist-upgrade auf einer Maschine zu fahren" meinst.

Darunter verstehen die meisten ein dist-upgrade auf die nächste Debian-Version, also z.B. Jessie->Stretch. Die Backports dabei einzubeziehen scheint mir erst mal völlig sinnlos.

Auf der anderen Seite passiert es manchmal, dass ein apt upgrade meldet, dass es einige zu aktualisierende Pakete nicht installieren konnte.

Solche Fälle lassen sich dann meist mit einem apt dist-upgrade lösen - ganz ohne Wechsel der Debian Version. Ich vermute, davon redest du hier.

Dass in solchen Fällen Backports-Pakete betroffen sind, habe ich zwar noch nicht erlebt, aber was in solchen Fällen passiert wäre in der Tat eine interessante Frage.

[guennid]

Darunter verstehen die meisten ein dist-upgrade auf die nächste Debian-Version, also z.B. Jessie->Stretch.

Das hatte ich mir schon so gedacht und deswegen ausdrücklich von einem gegebenen System geschrieben, allerdings erst im 2. Beitrag, zugegeben.

Es geht mir hier nicht um einen Versionswechsel, es geht mir lediglich um die Aktualisierung des gegebenen Systems einschließlich backports, z.B. wegen Sicherheitsaktualisierungen. Ich weiß ja nicht, wie "die meisten" das machen, aber ich mache es via dist-upgrade.

Dass in solchen Fällen Backports-Pakete betroffen sind, habe ich zwar noch nicht erlebt, aber was in solchen Fällen passiert, wäre in der Tat eine interessante Frage.

Ich schon. Wenn ich recht erinnere knallt es erst mal, wenn das "normale" dist-upgrade eine neuere (Sicherheits-)Version einer lib installieren will und das sich nicht verträgt mit dem/den installierten backports-Paketen. Lösen konnte ich das auch bisher schon relativ schnell, indem ich die backports-Pakete entweder separat einzeln upgradete oder (zumindest vorübergehend) deinstallierte.

Soweit mir bekannt, ist ein/der Unterschied zwischen upgrade und dist-upgrade (immer bei gegebener Version!) der, dass ein upgrade lediglich vorhandene Pakete upgradet und auch nur dann, wenn das möglich ist, während das dist-upgrade auch bisher nicht, aber jetzt eben erforderliche neue Pakete installiert. Letzeres möchte ich, soweit das die backports-Pakete betrifft, vermeiden oder mir zumindest genau anschauen, ob ich auch will, was das dist-upgrade will. Ergo frage ich mich, wie ich ein backports-verseuchtes (gegebenes!) System am schnellsten, aber auch relativ sicher auf den neuesten Stand bringe.

Beim dist-upgrade eines Versionswechsels würde ich völlig anders vorgehen, aber das ist hier nicht mein Thema.

Gibts das Paket nur in den Backports und ich will das installieren, dann reicht ein apt-get install paket aus.

Ich halte das für unzutreffend. Der neuere backports-Kern wird ohne explizite backports-Angabe nicht installiert.

[rendegast]

kleiner Einwurf:
backports bekommen per default Priority 100
(== Priority der installierten Pakete, sprich des Release 'a=now', das ermöglicht upgrades)
Priority 1 ist das default-Priority des Repo experimental.

'-t ....-backports' hebt dieses Repo temporär auf die Priority 990.

Gibts das Paket nur in den Backports und ich will das installieren, dann reicht ein apt-get install paket aus.

Ich halte das für unzutreffend. Der neuere backports-Kern wird ohne explizite backports-Angabe nicht installiert.

Die Aussage stimmt aber.
linux-image-amd64 aus backports hat zwar höhere Version, jedoch niedrigere Priority.
Somit ohne '-t stretch-backports' oder 'linux-image-amd64/stretch-backports' keine Installation.
Falls guennid sich auf das meta bezieht (was aber kein kernel ist), hätte er Recht.
'.... install linux-image-4.14......-amd64', also das kernel-paket selbst installiert sich aber ohne spezielle Angabe,
da kein gleichnamiges im Standard-Repo existiert,
und wenn keine problematischen Abhängigkeiten dem entgegenstehen.

Im Umfeld des kernel gibt es gelegentlich initramfs-tools in mehreren Versionen (noch kniffliger wenn die kernel-headers hinzukommen), somit ist guennids Beispiel nicht als Gegenargument für die Aussage tauglich.

Nichtsdestotrotz halte ich ein '-t stretch-backports' für empfehlenswert.






'... dist-upgrade -t stretch-backports'
naja. Genausogut könnte backports auch mit Priority 500 betrieben werden.
Problematisch dabei: backports-Pakete sind für das Funktionieren in einer Standard-Installation gedacht/gebaut,
nicht unbedingt, um mit anderen backports-Paketen zu funktionieren.
Bsp. kernel <-> nvidia-...-dkms (was sich aber durch ein späteres backports Paketes des nvidia löste)

[Radfahrer]

Darunter verstehen die meisten ein dist-upgrade auf die nächste Debian-Version, also z.B. Jessie->Stretch.

Ich habe das zwar noch nie darunter verstanden, aber genau aus dem Grund begrüße ich, dass es bei apt nicht mehr dist-upgrade, sondern full-upgrade heißt.

[guennid]

'.... install linux-image-4.14......-amd64', also das kernel-paket selbst installiert sich aber ohne spezielle Angabe, da kein gleichnamiges im Standard-Repo existiert

Gerade getestet. Stimmt!
Ich erinnere nur dunkel, das ich mal was aus den backports installieren wollte, das Paket aber erst mit -t [Version]-backports tatsächlich zur Installation angeboten wurde - die Erinnerung mag trügen.

naja. Genausogut könnte backports auch mit Priority 500 betrieben werden.

Pinning ist halt kompliziert, wie dein Beitrag meiner Meinung nach auch zeigt. Und tiefer einsteigen will ich eigentlich nicht.

... dist-upgrade -t stretch-backports'
[...]
Problematisch dabei: backports-Pakete sind für das Funktionieren in einer Standard-Installation gedacht/gebaut,
nicht unbedingt, um mit anderen backports-Paketen zu funktionieren.

Und genau das bringt mich zu meiner eigentlichen Frage, eher Vermutung, zurück: Wenn man sich die Mühe sparen will, bei jedem backports-Paket einzeln zu überprüfen, welche Konsequenzen sein upgrade hätte und trotzdem unangenehme Überraschungen möglichst vermeiden will, ist man mit

Code: Alles auswählen

apt-get -t stretch-backports upgrade

besser bedient - richtig?

genau aus dem Grund begrüße ich, dass es bei apt nicht mehr dist-upgrade, sondern full-upgrade heißt.

Nicht immer sind Namen Schall und Rauch, mitunter vermag man sich sogar was darunter vorzustellen.

[NAB]

Ich habe das zwar noch nie darunter verstanden, aber genau aus dem Grund begrüße ich, dass es bei apt nicht mehr dist-upgrade, sondern full-upgrade heißt.

Tut es das? Ich habe noch kein "dist upgrade" mit apt gemacht. Aber es versteht auch "dist-upgrade", steht nur nicht in der man-page, genau wie z.B. "--reinstall".

[Radfahrer]

Ja, ich weiß.
Ich vermute mal, das ist ein Zugeständnis an die Leute, die von apt-get das dist-upgrade gewohnt sind. Offiziell heißt es bei apt aber full-upgrade.