ubuntuusers.de

Das folgende läuft darauf hinaus, daß ich 2 Pakete gesperrt hatte, aber jetzt beim Upgrade von 22.04 auf 24.04 beide trotzdem gelöscht wurden und ich das bei einer Wiederholung des Upgrades unbedingt verhindern möchte.

Ich habe 2018 (unter Ubuntu 18.04) 2 Pakete via Synaptic gesperrt (Menü Paket / Version sperren). Einige Tage später habe ich den KDE-Plasma Desktop installiert (den ich seitdem benutze) und bald darauf festgestellt, daß die Sperre nicht funktioniert hat. Mir wurde gesagt, daß ich die Sperre wegen KDE nicht in Synaptic, sondern in Muon (auch ein grafischer Paketmanager) machen müsse. Also habe ich die 2 Pakete in Muon gesperrt (via rechte Maustaste / Derzeitige Version beibehalten). Ob ich vorher die 2 Pakete in Synaptic wieder entsperrt hatte, weiß ich nicht mehr.

Diese Sperre hat jetzt fast 7 Jahre funktioniert - bis ich vor kurzem von 22.04 auf 24.04 upgegradet habe. Denn dabei wurden beide gesperrten Pakete entfernt (und Muon übrigens auch). Es handelt sich um eine bestimmte Compiler-Version, die ich unbedingt erhalten möchte (und von der ich weiß, daß sie auch unter 24.04 läuft - sie wird lediglich dort nicht mehr zum installieren angeboten). Das kürzliche Upgrade habe ich auf einem Test-PC gemacht (der ein Klon meines Haupt-PCs war). Das Upgrade auf dem Haupt-PC steht demnächst an. Dabei möchte ich unbedingt verhindern, daß diese 2 Pakete wieder entfernt werden.

Anbei 2 screenshots vom noch nicht upgegradeten Haupt-PC (mit 22.04), wo Ihr die Sperre in Synaptic und Muon sehen könnt sowie 2 screenshots vom upgegradeten Test-PC (mit 24.04), wo jetzt in Synaptic stattdessen eine neuere Version von einem der 2 Pakete gesperrt ist (Muon wurde beim Upgrade ja entfernt).

Ich vermute, daß meine Sperre irgendwie nicht "richtig" gesetzt war. Vielleicht durch die o.g. Synaptic/Muon-Kombi, vielleicht hängt es auch damit zusammen, daß Muon beim Upgrade entfernt wurde und dabei dessen Sperre vielleicht "verloren" ging? Zusatz-Info: beim booten von 22.04 wird ein Ubuntu-Logo angezeigt, beim booten von 24.04 hat sich das in ein Kubuntu-Logo geändert.

Ich bräuchte mal jemanden, der sich mit dem Thema gut auskennt und mir sagen kann, wie ich auf dem Haupt-PC (22.04) sicherstellen kann, daß die Sperre dieser 2 Pakete "niet und nagelfest" ist. Herzlichen Dank im Voraus.

Synaptic und Muon sind nur alternative GUIs der Paketverwaltung.

Muon wird durch Discover ersetzt. Vorsicht - ich nutze kein Kubuntu, kenne also die Details nicht.

Terminal ist universeller, "apt-mark hold" etc.

Das ist aber alles unwichtig.

Das Release Upgrade wird -vermutlich- mit gesperrten Paketen stehen bleiben, um keinen Schaden zu verursachen. Was ja Sinn macht ... 👍

P.S. Bilder schauen sich viele Supporter nicht an, Terminalausgabe im Codeblock ist besser.

hakel2022 schrieb:

Das Release Upgrade wird -vermutlich- mit gesperrten Paketen stehen bleiben, um keinen Schaden zu verursachen.

Danke für Deinen Post. Solange das niemand zu 100% sicher vorhersagen kann, möchte ich es gerne probieren. Und vorher diese 2 Pakete so korrekt + gründlich sperren wie nur möglich.

P.S. Bilder schauen sich viele Supporter nicht an, Terminalausgabe im Codeblock ist besser.

Die Anzeige von Synaptic / Muon kann man ja schlecht in einen Codeblock packen. Und wenn jemand wirklich helfen möchte könnte der 1 Mausklick pro Bild hilfreich sein. Weil ein Vorschlag, der dann doch nicht funktioniert, nützt ja keinem.

Terminal ist universeller, "apt-mark hold" etc.

Habe mal nach "apt-mark" recherchiert und auf dem noch nicht upgegradeten Haupt-PC (mit 22.04) mal "sudo apt-mark showhold" gestartet und die Ausgabe war leer. Möglicherweise haben wir da ja schon das Problem oder zumindest einen Teil davon.

Da auf demselben PC aber Synaptic + Muon gesperrte Pakete anzeigen (siehe screenshots), speichern diese beiden Programme diesen Zustand offensichtlich woanders. Und da Synaptic ja nicht funktioniert hat, Muon aber schon (s.o.) speichern diese beiden Programme diesen Zustand offensichtlich sogar unterschiedlich...

Gefunden habe ich dazu auf demselben PC (mit 22.04) im Ordner /etc/apt/preferences.d/ 2 vermutlich zugehörige files:

hg6@i3300:/etc/apt/preferences.d$ cat fpc
Package: fpc
Pin: version 3.0.4
Pin-Priority: 1001
hg6@i3300:/etc/apt/preferences.d$ cat fpc-src
Package: fpc-src
Pin: version 3.0.4
Pin-Priority: 1001
hg6@i3300:/etc/apt/preferences.d$

Wie sollte ich bei dieser Ausgangslage vorgehen, damit diese 2 Pakete so korrekt + gründlich gesperrt sind wie es nur möglich ist? Ich kann auch gerne vorher noch weiteres für Euch prüfen, wenn mehr Infos das Ergebnis sicherer machen.

Warum stellst du nicht den Zustand vor Upgrade auf dem Testrechner wieder her und testest was raus kommt wenn du mit apt-hold arbeitest?

Das Problem (Synaptic & Muon) hast du ja nun schon identifiziert.

Synaptic setzt eine eigene Sperrdatei, die nur von Synaptic genutzt wird.

APT kennt die nicht und ignoriert diese, somit kann das bei einem Upgrade gar nicht funktionieren.

Die Bugmeldung dazu ist quasi noch ganz frisch und wird ganz bestimmt ASAP bearbeitet. 🙄

• https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=276655

• 42178

schwarzheit schrieb:

Warum stellst du nicht den Zustand vor Upgrade auf dem Testrechner wieder her und testest was raus kommt wenn du mit apt-hold arbeitest? Das Problem (Synaptic & Muon) hast du ja nun schon identifiziert.

So ein Test macht Sinn, aber er ist mit nicht unerheblichem Aufwand verbunden (den Klonvorgang wiederholen, der einige Handarbeit erfordert, weil die Hardware der 2 PC's komplett unterschiedlich ist, vorher muß Track 0 wiederhergestellt werden, der durch das Upgrade verändert wurde, dann das Upgrade inkl. seiner Vorbereitungen wiederholen und der Test-PC ist auch älter und langsam). Daher bin ich nicht wild darauf, dieses Spiel "unnötig oft" durchzuführen. Lieber vorher ein bischen überlegen, damit ich das "Spiel" möglichst nur 1x machen muß 😉

Da "sudo apt-mark showhold" eine leere Ausgabe lieferte, denke ich auch, daß vor dem nächsten Versuch unbedingt "sudo apt-mark hold" verwendet werden sollte. Aber unklar ist für mich z.B. noch:

• sollen die bisherigen Sperren in Synaptic bzw. Muon bewusst bleiben oder besser vorher entfernt werden?

• wenn entfernen, in welcher Reihenfolge?

• und wenn entfernen, zu welchem Zeitpunkt? Zu den Vorbereitungen des Upgrades gehören ja sudo apt update + sudo apt upgrade + sudo apt dist-upgrade und es nützt ja nichts, wenn dann dabei schon die betreffenden Pakete entfernt oder geupdatet würden.

tomtomtom schrieb:

Synaptic setzt eine eigene Sperrdatei, die nur von Synaptic genutzt wird.

Ok. Aber wegen KDE kam es hier nach meinem Verständnis eher oder sogar nur auf Muon an.

APT kennt die nicht und ignoriert diese, somit kann das bei einem Upgrade gar nicht funktionieren.

Das klingt plausibel.

Die Bugmeldung dazu ist quasi noch ganz frisch und wird ganz bestimmt ASAP bearbeitet. 🙄

Die beiden Meldungen sind von 2004 und 2006, das hast Du wohl ironisch gemeint...

Ich habe vieles darin nicht verstanden, aber "dpkg hold" kam sehr oft in beiden vor. Gibt es von "dpkg" auch einen Befehl zum Sperren von Paketen? Wenn ja: sollte ich in meinem Fall besser "sudo apt-mark hold" oder besser "dpkg hold" verwenden? (oder beide?)

Hartmut2 schrieb:

So ein Test macht Sinn, aber er ist mit nicht unerheblichem Aufwand verbunden (den Klonvorgang wiederholen, der einige Handarbeit erfordert,...

Kein Backup - Kein Mitleid. ¯\_(ツ)_/¯

@schwarzheit: da hast Du mich missverstanden. Ich habe natürlich ein Backup (das vom Haupt-PC). Wenn ich nach dem Klonen auf den Test-PC davon nochmal ein Backup erstellt hätte, dann hätte die Zeit dafür (plus dieses Backup jetzt wiederherzustellen) ungefähr genauso lange dauert wie jetzt das Klonen zu wiederholen. Hätte also in dem Fall, wenn eine Wiederholung nötig ist, nix gespart und wenn keine Wiederholung nötig ist (so wie bei den bisherigen Upgrades), unnötig Zeit gekostet.

Kannst Du denn zu den offenen Fragen etwas beisteuern?

Hartmut2 schrieb:

• sollen die bisherigen Sperren in Synaptic bzw. Muon bewusst bleiben oder besser vorher entfernt werden?

Wurscht. Weil werden von apt eh ignoriert.

• wenn entfernen, in welcher Reihenfolge?

Wurscht. Weil werden von apt eh ignoriert.

• und wenn entfernen, zu welchem Zeitpunkt? Zu den Vorbereitungen des Upgrades gehören ja sudo apt update + sudo apt upgrade + sudo apt dist-upgrade und es nützt ja nichts, wenn dann dabei schon die betreffenden Pakete entfernt oder geupdatet würden.

Wurscht. Weil werden von apt eh ignoriert.

Und sudo apt update && sudo apt upgrade gehört ja nicht nur zur Upgradevorbereitung sondern sollte generell regelmäßig gemacht werden. Genauso wie System putzen. Am einfachsten geht das mit nem alias. Z.B. so:

alias akt='sudo apt update && sudo apt upgrade && sudo snap refresh && sudo apt autopurge && sudo apt clean && sudo apt purge ~c'

Also generell gesagt:

Synaptic und Muon Einstellungen haben logischerweise nur Einfluss wenn Updates / Upgrades auch damit gemacht werden. Was bei Upgrades nicht der Fall ist.

Andersrum werden aber Einstellungen die mit apt erstellt wurden auch von Synaptic und Muon eingehalten. Weil Synaptic / Muon nur grafisch auf apt aufsetzen.

Paket auf hold setzen:

• https://www.cyberciti.biz/faq/apt-get-hold-back-packages-command

• apt/apt-Kommandos (Abschnitt „apt-mark“)

Dann gibts auch noch APT-Pinning:

• APT-Pinning

Und Muon funktioniert auch noch auf Oracular Oriole

• https://forum.ubuntuusers.de/topic/neuer-artikel-baustelle-muon/3/#post-9452767

@schwarzheit: Danke für Deine Antwort. Damit wären schonmal 3 Fragen geklärt ☺

schwarzheit schrieb:

Also generell gesagt: Synaptic und Muon Einstellungen haben logischerweise nur Einfluss wenn Updates / Upgrades auch damit gemacht werden.

Ich habe Updates (fast) nie mit Synaptic oder Muon gemacht. Sondern (fast) immer nur über den automatischen Update-Mechanismus (in KDE erscheint in der Taskleiste ein Pfeil-Icon mit blauem Punkt, wenn Updates verfügbar sind und wenn man darauf klickt, kann man sehen, was für Updates das sind und diese starten). Die in meinem 1. Beitrag beschriebene Sperre via Muon hat auf genau diesen "automatischen Update-Mechanismus" erfolgreich gewirkt (die Sperre davor, via Synaptic, jedoch nicht). D.h. Muon Einstellungen wirken definitiv nicht nur innerhalb von Muon, sondern auch auf diesen "automatischen Update-Mechanismus".

Damit bleibt erstmal nur noch diese Frage offen:

Gibt es von "dpkg" auch einen Befehl zum Sperren von Paketen? Wenn ja: sollte ich in meinem Fall besser "sudo apt-mark hold" oder besser "dpkg hold" verwenden? (oder beide?)

trollsportverein schrieb:

Paket auf hold setzen:

• https://www.cyberciti.biz/faq/apt-get-hold-back-packages-command

• apt/apt-Kommandos (Abschnitt „apt-mark“)

Danke für Deinen Post. Mein Problem ist nicht die Syntax zu einem Sperr-Befehl zu finden, sondern in einer so ungewöhnlichen "Situation" den am wahrscheinlichsten funktionierenden Sperr-Befehl auszuwählen. Damit bin ich mit meinem Level überfragt und suche hier Hilfe von einem Experten.

Dann gibts auch noch APT-Pinning:

• APT-Pinning

Der Artikel beschreibt Steuer-Dateien im Ordner /etc/apt/preferences.d/ den ich ja auch schon bei mir gefunden und 2 interessante files darin oben gepostet hatte (siehe 9472124). Aber diese haben ja offensichtlich nicht funktioniert. Die weiteren Details in diesem Artikel habe ich nicht wirklich verstanden (d.h. ob und wie genau man die 2 besagten files ändern müsste, damit es funktioniert).

Frage: willst Du mit diesem Link sagen, daß z.B. eine Sperre via "sudo apt-mark hold" nicht funktionieren wird und eine korrekte Steuer-Dateien in /etc/apt/preferences.d/ nötig ist?

Und Muon funktioniert auch noch auf Oracular Oriole

• https://forum.ubuntuusers.de/topic/neuer-artikel-baustelle-muon/3/#post-9452767

Bin immer wieder begeistert, was in Linux alles so möglich ist (wenn man weiß, wie). Falls ich nach dem Upgrade mit Synaptic / Discover nicht zufrieden bin, werde ich es mal versuchen.

Hartmut2 schrieb:

@schwarzheit: Danke für Deine Antwort. Damit wären schonmal 3 Fragen geklärt ☺

schwarzheit schrieb:

Also generell gesagt: Synaptic und Muon Einstellungen haben logischerweise nur Einfluss wenn Updates / Upgrades auch damit gemacht werden.

Ich habe Updates (fast) nie mit Synaptic oder Muon gemacht. Sondern (fast) immer nur über den automatischen Update-Mechanismus (in KDE erscheint in der Taskleiste ein Pfeil-Icon mit blauem Punkt, wenn Updates verfügbar sind und wenn man darauf klickt, kann man sehen, was für Updates das sind und diese starten). Die in meinem 1. Beitrag beschriebene Sperre via Muon hat auf genau diesen "automatischen Update-Mechanismus" erfolgreich gewirkt (die Sperre davor, via Synaptic, jedoch nicht). D.h. Muon Einstellungen wirken definitiv nicht nur innerhalb von Muon, sondern auch auf diesen "automatischen Update-Mechanismus".

Denk doch bitte mal logisch mit.

Muon = Bestandteil von Kubuntu = grafische Updates werden auch damit und dessen Einstellungen gesteuert - das erklärt warum es damit klappt und mit Synaptic nicht.

ABER grafische Tools setzen IMMER auf apt auf. Also stells gescheit mit apt ein, dann ist das grafische Tool auch wurscht. Und logischerweise würde es dann auch sowohl mit Muon wie auch Synaptic funktionieren.

Also, Muon macht das Paket halten über das APT-Pinning. Beispielsweise hier und heute 7zip:

cat /etc/apt/preferences.d/7zip
 
Package: 7zip
Pin: version 24.09+dfsg-2
Pin-Priority: 1001

Fällt was bei der Versionsangabe auf?

Muon ist nur ein grafisches Frontend, das nutzt auch nur das normale APT-Paketmanagment, Muon macht keine Fisimatenten, oder beschreitet Sonderwege.

Hartmut2 schrieb:

Ok. Aber wegen KDE kam es hier nach meinem Verständnis eher oder sogar nur auf Muon an.

Synaptic ist es egal, unter welcher Oberfläche du es nutzt. Wenn du dort etwas sperrst ist es gesperrt - aber eben nur in Synaptic.

Die beiden Meldungen sind von 2004 und 2006, das hast Du wohl ironisch gemeint...

Und da hab ich extra noch nen Smiley gesetzt.😈

Ich habe vieles darin nicht verstanden, aber "dpkg hold" kam sehr oft in beiden vor.

Das ist die Empfehlung des Maintainers von Synaptic, da er offensichtlich nicht vor hat, den Bug zu fixen.

Im Übrigen findet sich unter Kommentar #51 ein funktionierender Würgaround.

Mit dem der Maintainer durch einen einzigen Eintrag in seiner debian/postinst (und wenn er sauber arbeitet einem weiteren, entgegengesetzten in der debian/prerm) den Bug beheben könnte - aber da er es offenbar nicht als Bug, sondern als Feature ansieht...

Gibt es von "dpkg" auch einen Befehl zum Sperren von Paketen?

Ist ja nicht so, dass der alleine in der Bugmeldung und den Kommentaren mehrfach genannt wird. 😉

Wenn ja: sollte ich in meinem Fall besser "sudo apt-mark hold" oder besser "dpkg hold" verwenden? (oder beide?)

dpkg bietet sich an, wenn du nicht direkt mit apt arbeitest (wie es unter KDE Neon standardmäßig gehandhabt wird), ansonsten ist das recht wumpe.

Hartmut2 schrieb:

Gibt es von "dpkg" auch einen Befehl zum Sperren von Paketen?

Um es kurz zu machen, ja, foo hier als fiktives Beispielpaket:

echo foo 1 install | dpkg --set-selections

Siehe auch:

• https://help.ubuntu.com/community/PinningHowto#Dpkg