Zwei Distros in sources.list / tomcat9 in Bookworm patchen

[miyata]

Hallo,

ich möchte einen Bullseye Server auf Bookworm upgraden. Allerdings läuft die Anwendung auf dem Server nicht mit tomcat10 sondern nur mit tomcat9.

Beim Upgrade wird der tomcat9 ja erst einmal nicht entfernt und läuft weiter. Da ich ihn (bis die Anwendung tomcat10 fähig wird) noch eine Weile benötigen werde, bin ich auf die Bullseye Updates für ihn angewiesen.

Zwei Fragen:

Kann ich für die Restlebensdauer von Bullseye in meiner sources.list nach dem Upgrade auf Bookworm sowohl eine Zeile für Bullseye als auch eine für Bookworm haben, damit mein tomcat9 weiter gepatcht wird, oder wird mir das Probleme machen?

Wie werde ich nach dem Upgrade auf Bookworm alles nicht mehr benötigte mit apt purge '~c' und apt purge '~o' los ohne mir den tomcat9 wegzuwerfen?

Danke für Eure Hilfe!
Miyata

[cosinus]

Das würde ich sein lassen. Dann lieber mit 'apt-mark hold' die noch benötigten Pakete festpinnen also auf status hold setzen, damit apt die nicht entfernt.

[hikaru]

Eigentlich™ sollte das funktionieren, Bullseye in der sources.list zu belassen, und weiterhin Updates für die von dort kommenden Pakete zu bekommen, wenn es keie Konflikte zu Bookworm-Paketen gibt. Das ist ja im Prinzip nichts anderes, als Pakete aus höheren Releases zu pinnen, nur andersrum. Allerdings sollten solche Situationen bei sauberer Paketpflege nicht auftreten, meine ich.

Ich kenne mich mit Tomcat nicht aus, aber wenn tomcat9 im Zuge des dist-upgrades nicht entfernt wird (z.B. wegen eines Konflikts mit tomcat10), und eine reguläre Bookworm-sources.list (ohne Bullseye) verwendet wird, dann bleibt tomcat9 ja als ungepflegte Leiche auf dem System liegen, potenziell bis in alle Ewigkeit. Sowas würde ich als Bug betrachten.

[miyata]

bleibt die Frage, ob das Paket tomcat9 wenn es dann auf hold ist weiterhin Bullseye Patches erhält

[hikaru]

bleibt die Frage, ob das Paket tomcat9 wenn es dann auf hold ist weiterhin Bullseye Patches erhält

Nein, wenn du es auf hold setzt, bekommt es keine Updates mehr, egal aus welchem Release. Es ist aber auch gar nicht nötig, es auf hold zu setzen, wenn es in Bookworm keinen Grund gibt, es zu entfernen.

[miyata]

" dann bleibt tomcat9 ja als ungepflegte Leiche auf dem System liegen, potenziell bis in alle Ewigkeit. Sowas würde ich als Bug betrachten. "
apt purge '~c' apt purge '~o' wirft das ja weg, nur das initiale apt full-ugrade lässts liegen, damit eine damit laufende Anwendung nicht kaputt geht.

[miyata]

würde pinning mit

Package: tomcat9*
Pin: release a=bullseye

für weitere updates sorgen (so bullseye denn weiterhin in sources.list sei) und vor entfernen durch apt purge '~o' schützen?

[cosinus]

" dann bleibt tomcat9 ja als ungepflegte Leiche auf dem System liegen, potenziell bis in alle Ewigkeit. Sowas würde ich als Bug betrachten. "
apt purge '~c' apt purge '~o' wirft das ja weg, nur das initiale apt full-ugrade lässts liegen, damit eine damit laufende Anwendung nicht kaputt geht.

Aber genau das ist Sinn und Zweck von hold. Eben damit apt keine alten Pakete weghaut. Müsste man im Einzelfall testen, aber ich denke durch ein dist-upgrade auf bookworm, wird apt tomcat9 auf 10 updaten wollen, zumindest den Hinweis geben, welche Pakete alt sind.

Alternativ einfach bei bullseye bleiben bis die Anwendung auch mit einem neuen tomcat läuft.

[KP97]

Du kannst mit einem zusätzlichen -s in dem Befehl simulieren, was passieren würde, wenn ...

[michaa7]

würde pinning mit

Package: tomcat9*
Pin: release a=bullseye

für weitere updates sorgen (so bullseye denn weiterhin in sources.list sei) und vor entfernen durch apt purge '~o' schützen?

Meinem ***mangelhaften*** Verständnis der Pinningeinzelheiten nach ***sollte*** das tun was du willst. Updates für tomcat9* sollten so weiterhin aus bullseye gezogen werden.

Alternativ setzt du tomcat auf hold. Updates werden dann nicht automatisch geholt. Du würdest aber mit apt-upgrade sehen ob und welche *neuen* tomcatxy pakete *zurückgehalten* werden. Ggf. könntest du diese Pakete dann manuell mit Angabe der Version installieren.

[reox]

Hin und wieder hab ich das auch schon gebraucht, für Pakete die irgendwann mal rausgeflogen sind. Compiler sind ja auch sowas - da kommt mit jedem release eine neue Version (zB. clang-11, clang-13, ...). Wenn man die alten Versionen braucht, ist das oft ein gangbarer Weg.

Die Frage ist halt immer ob es eine Abhänigkeit gibt die nicht aufgelöst werden kann (zB. eine library die in bookworm zu neu ist) oder ob es sogar eine break regel gibt (es gibt pakete die explizit verlangen, dass die alte version deinstalliert werden muss).
Da das Paket auch nicht in bookworm ist, brauchst du nicht mal einen Pin anlegen.
Updates aus bullseye-security würden auch normal angewendet, da ja ebenfalls keine neuere Version in bookworm liegt.

[michaa7]

... da ja ebenfalls keine neuere Version in bookworm liegt.

Aber jederzeit dort eintrudeln könnte.

[reox]

... da ja ebenfalls keine neuere Version in bookworm liegt.

Aber jederzeit dort eintrudeln könnte.

Unwahrscheinlich. Also denke ich mal... Es gibt ja viele Beispiele für solche Pakete, wo nur die aktuelle Major Version paketiert wird.

Außerdem: Das Problem ist hier nicht tomcat9.x sondern das es mit der 10er nicht geht. dH wenn eine Version von tomcat9 in bookworm auftaucht, ist das ja nur positiv und man möchte die wohl auch updaten.

[michaa7]

... dH wenn eine Version von tomcat9 in bookworm auftaucht, ist das ja nur positiv und man möchte die wohl auch updaten.

... da hatte ich dich wohl missverstanden. Natürlich will der user in diesem Fall eine neuere tomcat9 Version. Ich hatte "neuere Version" als tomcat10 interpretiert.

[reox]

... dH wenn eine Version von tomcat9 in bookworm auftaucht, ist das ja nur positiv und man möchte die wohl auch updaten.

... da hatte ich dich wohl missverstanden. Natürlich will der user in diesem Fall eine neuere tomcat9 Version. Ich hatte "neuere Version" als tomcat10 interpretiert.

Ja - das Problem was dabei auftreten kann wäre, wenn tomcat10 zur deinstallation von tomcat9 auffordert, weil es zB gegen tomcat9 als Conflict, Breaks oder Replaces eingetragen ist. Ein weiterer Spezialfall sind Pakete die ein virtuelles Paket bereitstellen (Provides).
Insbesondere durch ein Replaces oder Provides würde bei einem dist-upgrade IMO dann das neue Paket installiert - und dann muss man das zwangsläufig pinnen.
In diesem Fall aber unproblematisch, da tomcat9 und tomcat10 offenbar problemlos co-existieren können