[erledigt] Paket-Upgrade via apt von "Fremd-Software"???

[TomL]

Moin

Gerade eben hatte ich ein verblüffendes Erlebnis... was ich eigentlich gar nicht für möglich gehalten habe. apt full-uprade hat gerade das von mir selbstkompilierte deb-Paket Openvpn aktuell aus den Backports upgedatet.... was in den ganzen Jahre zuvor noch nie passert ist. Meine erste Reaktion war "häh? wasn das?"

Die Fakten:

• die derzeitige Stretch-Version von OpenVPN-Version ist 2.4.0
• im August 2018 hatte ich die Version 2.4.6 kompiliert und somit anschließend nur das Binary (ohne die obligatorischen init.d-Begleit-Files) via dpkg -i installiert
• im Winter habe ich wegen aktuellerer nftables zusätzlich die Backports in den sources-liste eingetragen und von dort installiert
• gerade hat apt mein manuelles Paket openvpn aus den Backports auf die Version 2.4.7 upgedatet

Ist das normal, dass sich apt in manuell installierte Pakete einmischt? Aufgefallen ist mir das anhand Fehlermeldungen im Journal, weil nach dem Upgrade und Reboot jetzt auch auf einmal der alte sysvinit-Kram für openvpn vorhanden war und der start des Daemon in den runlevels eingetragen war. Das ist natürlich mit meinen eigenen Service-Units kollidiert. Aber die Frage ist: Wieso mischt sich apt überhaupt in die manuell installierten Pakete ein...? .... was mir in den ganzen Jahre nie aufgefallen ist.Und ich hatte ja immer schon einige selbst-kompilierte Pakete im Einsatz.

[DeletedUserReAsG]

Wenn eine verfügbare Version höher als eine Installierte ist, wird’s geupdated. Das ist normal. Wenn du das nicht möchtest, könntest du die betreffenden Pakete z.B. auf hold setzen.

[KP97]

Wie @niemand schon sagt, das ist normal.
Wenn ich Pakete selbst kompiliere, setze ich die Version immer so hoch, daß ich sicher bin, im Repo wird so eine Version nie erscheinen.
Das erspart mir ein pinning und ich kann immer sofort sehen, daß es mein eigenes Paket ist.
Ich nutze checkinstall, da kann man das sehr bequem angeben.

[wanne]

Wenn ich Pakete selbst kompiliere, setze ich die Version immer so hoch, daß ich sicher bin, im Repo wird so eine Version nie erscheinen.

Der joke muss jetzt einfach sein: Du hast noch nie was von Systemd gehört

[TomL]

Jetzt bekomme ich eine Vorstellung von den Zusammenhängen.... die mir vorher so gar nicht bewusst waren, weil es vorher noch keine solche Situation gab. Solange die Backports nicht eingetragen sind, bleibt eine manuell kompilierte höhere Version ja zwingender Weise immer oberhalb der Stable-Version, die deshalb auch nie angepackt wird. Aber mit der Einbindung der Backports für ein beliebiges anderes Paket (bei mir nftables), wird anscheinend festgestellt, dass für das via dpkg regulär installierte OpenVPN-Eigen-Paket in den Backports eine höhere Version existiert, die dann auch übernommen wurde.

Mich hat nur der Umstand irritiert, weil in den Backports ja nur höhere Versionen (im Vergleich zu stable) vorhanden sind und das dieser Upgrade eben nur mein eigenes Paket aktualisiert hat, aber alles andere nicht. Das war mir halt neu. An dieser Stelle bin ich ja noch nicht mal gegen das Upgrade, ganz im Gegenteil ... mir gefällt bei OpenVPN nur seit jeher nicht, was da noch so installiert wird.... ich machs halt lieber unter eigener Kontrolle mit eigenen Service-Units und dieses Upgrade hat erst mal einiges durcheinander gebracht.

@KP97, danke für den Tip, den werde ich genau so übernehmen. Ich nutze auch checkinstall und lasse mir ebenfalls damit die eigenen Pakete erstellen. Ich belasse einfach künftig die Version als solche, damit ich erkennen kann, welche es ist, mache aber aus 2.4.6 zum Beispiel 100.2.4.6... damit bin ich dann auf jeden Fall drüber und kann trotzdem sehen, welche es ist.

[novalix]

Der Grund, warum die Backport-Pakete nicht die Pakete aus stable überschreiben, ist die per Voreinstellung niedrigere "Pin-Priority".
Ein selbst erstelltes Paket erhält entweder eine noch niedrigere oder wahrscheinlich gar keine Priorität, es sei denn man vergibt sie.
Ich kann das hier jetzt nicht prüfen, mangels eigener Pakete.

Wenn man sich also schon die Mühe macht, die Compiler-Orgel zu bepumpen, könnte man auch noch einen kleinen Eintrag unter preferences.d hinterlassen. So wie dieser Mann.

[KP97]

Der joke muss jetzt einfach sein: Du hast noch nie was von Systemd gehört ;-)

Ähm, wie meinen?
Ich erstelle ein Paket wanne.deb in Version 10 und installiere das mit dpkg -i, und nun erklärst Du uns mal, was systemd dabei macht...

[DeletedUserReAsG]

Vielleicht bezog’s sich auf die relativ hohe und verhältnismäßig schnell hochzählende Versionsnummer von systemd? Allerdings gibt’s da noch ganz andere Hausnummern: josm, z.B., ist derzeit bei 14824 (https://josm.openstreetmap.de/wiki/Download).

[rendegast]

Es geht um Version UND Priority.
man apt_preferences

Zu dieser Versions-Arithmetik gibt es wohl schon etliche Beiträge.

Tool
apt-cache policy
apt-cache policy paket ...

Die Policy eines lokalen Repo ist der elegantere Weg als die Paketversion künstlich hochzuzählen.

[KP97]

@rendegast
Sicher gibt es elegantere Wege, aber hier geht es vielleicht um drei, vier Pakete die man selbst kompiliert, also um eine überschaubare Anzahl, und nicht um einen ganzen Desktop.
Da ist das bestimmt die einfachere Lösung.

@wanne
Nachdem mich @niemand aufgeklärt hat, habe ich jetzt auch Deinen Scherz verstanden...hat etwas gedauert...;-)

[wanne]

Vielleicht bezog’s sich auf die relativ hohe und verhältnismäßig schnell hochzählende Versionsnummer von systemd?
Ja. Und vor allem um den Sprung um 50 Versionen, die nie veröffentlicht wurden von ~140 auf 183.

Allerdings gibt’s da noch ganz andere Hausnummern: josm, z.B., ist derzeit bei 14824 (https://josm.openstreetmap.de/wiki/Download).

Deuche Java Programmierer müssen außer Konkurrenz laufen. Wobei zumindest das erste Kriterium ja auch auf systemd zutrifft.

[TomL]

Sicher gibt es elegantere Wege, aber hier geht es vielleicht um drei, vier Pakete die man selbst kompiliert, also um eine überschaubare Anzahl, und nicht um einen ganzen Desktop.Da ist das bestimmt die einfachere Lösung.

Ich sehe das mit der künstlich hohen Versionsnummer auf jeden Fall als einfacher... und zwar dann, wenn man das gleiche Paket auf mehreren Endgeräten installieren will. Mit der "falschen" Versionsnummer ist dann bei jedem Einzelfall nichts an weiteren Maßnahmen erforderlich. Der jeweilige Mehr-Aufwand mit eigenen Apt-Policies entfällt dabei.