CachyOS updatet nicht

[Drakon111]

Moin!!

Wollte heute Morgen auf 2 PCs Updates machen (einer am TV für Multimedia, andere für alles andere), jetzt blockiert aber ein oder mehrere Programme, das update, was macht ich jetzt?


Was ich gemacht habe:
Mit Paru und-Syu probiert
Libprotobuf-lite.so und protbuf neu zu installieren

Ergänzung (Heute um 06:54)

❯ paru
[sudo] Passwort für basti:
:: Paketdatenbanken werden synchronisiert …
cachyos-v3 ist aktuell
cachyos-core-v3 ist aktuell
cachyos-extra-v3 ist aktuell
cachyos ist aktuell
core ist aktuell
extra ist aktuell
multilib ist aktuell
:: Vollständige Systemaktualisierung wird gestartet …
Warnung: firefox: Lokale Version (152.0.1-1.1) ist neuer als extra (152.0.1-1)
Abhängigkeiten werden aufgelöst …
Nach in Konflikt stehenden Paketen wird gesucht …
Fehler: Vorgang konnte nicht vorbereitet werden (Kann Abhängigkeiten nicht erfüllen)
:: Installation von protobuf (35.1-1.1) verletzt Abhängigkeit »libprotobuf-lite.so=35.0.0-64«, benötigt von mixxx

 

[Mircosfot]

Hatte gestern ebenso das Problem. Da es in der Vergangenheit Probleme mit verseuchten Paketen gab, wird wohl gerade alles ausgesetzt. Ein paar Tage ohne Updates fahren ^.^.

 

[mibbio]

Da es in der Vergangenheit Probleme mit verseuchten Paketen gab, wird wohl gerade alles ausgesetzt.

Das betrifft aber höchstens das AUR und hat mit dem Problem des TE erstmal nichts zu tun.

Das Aktualisieren scheitert bei ihm ja bereits an den regulären Paketen aus den normalen Repositories, die entschiedende Zeile in der Fehlermeldungist dabei:

Installation von protobuf (35.1-1.1) verletzt Abhängigkeit »libprotobuf-lite.so=35.0.0-64«, benötigt von mixxx

Es gibt schlicht einen Namenskonflikt mit einem installierten Paket. Pacman (was intern von paru aufgerufen wird) will "protobuf" installieren bzw. aktualisieren, weil ein installiertes Paket ("mixx") dieses zwingen in einer bestimmten, älteren Version als Abhängigkeit hat. Pacman will protobuff auf 35.1aktualisieren, mixx will aber ausschließlich Version 35.0.0 haben.

Eine Lösung wäre jetzt, das Paket "mixx" zu deinstallieren, damit das Update funktioniert. Danach kann man dann Mixx wieder installieren, weil es bei einer Neuinstallation dann auch protobuf in Version 35.1 als Abhängigkeit hat.

 

[Drakon111]

Eine Lösung wäre jetzt, das Paket "mixx" zu deinstallieren

Das hat geholfen, danke

 

[mibbio]

Kannst anschließend nach dem Update dann Mixx auch wieder installieren. Denn das aktuelle Paket von Mixx im Repository hat dann auch 35.1 als Abhängigkeit.

 

[Drakon111]

Mixxx ist mir aktuell nicht so wichtig, von daher kann ich auch erstmal darauf verzichten und es gibt ja noch alternativen

 

[mibbio]

Das wieder zu installieren, wäre nach dem Update aber völlig unproblematisch. Das Problem war nur, dass das bisher noch installierte Paket von Mixx halt eine ältere Version von protobuf haben wollte und damit das Aktualisieren von protobuf blockiert hatte.

Pacman geht beim Aktualisieren recht pragmatisch vor. Es sieht, dass protobbuf aktualisiert werden soll und auch, dass mixx aktualisiert werden muss. Es werden dann für jedes zu aktualisierende Paket separat die Abhängkeiten geprüft.

Dabei stellt pacman fest, dass protobuf nicht aktualisiert werden kann, weil die noch installierte Version von Mixx halt eine ältere protobuf-Version braucht und Mixx kann pacman aber auch nicht aktualisieren, weil das eine andere Version von protobuf will, als die aktuell noch installierten.

Protobuf kann erst aktualisiert werden, wenn mixx aktualisiert ist und umgekehrt müsste für das Updaten von mixx erst protobuf aktualisiert werden - beide Updatevorgänge blockieren sich quasi gegenseitig. Die Lösung ist dann, vorübergehend eines der beiden Pakete durch Deinstallation erstmal aus der Gleichung rauszunehmen und es nach dem Update dann wieder zu installieren.

 

[Drakon111]

Mache ich nachher, wenn ich wieder Zeit habe

 

[Moov]

Solche Bugs sind schade und nerven. Meine Motivation von Win11 dauerhaft auf Cashy und co zu wechseln bekommt dann immer mal wieder einen Dämpfer. Danke für die Lösung.

 

[tomgit]

Solche Bugs sind schade und nerven.

Als Nvidia-Nutzer sollte man nervigere Bugs unter Windows gewohnt sein...
Wenn die Abhängigkeiten das gröößte Problem darstellt, gibt es hierfür gute Alternativen. Unter Fedora sollte es sowas etwa nicht geben, entsprechend auch auf Derivaten von Fedora, wie Bazzite. Jedes OS hat seine Quirks.
Immerhin gibt einem CachyOS mit, wo das Problem zu finden ist und dann kann man als User noch selbst entscheiden, ob man das fixen mag oder fürs erste ignoriert.

 

[mibbio]

Solche Bugs sind schade und nerven.

Es ist kein Bug, sondern schlicht die gewollte Funktionsweise des Paketmanagers pacman. Bei der Installation einzelner oder auch mehrerer Pakete (Aktualisieren ist im Grunde auch ein (Drüber-)Installieren von Paketen), für jedes Paket einzeln, ob es sich unter Einhaltung der Abhängigkeit im aktuellen Systemzustand konfliktfrei installieren lässt.

Wenn dem irgendein anderes Paket aufgrund seiner derzeit installierten Version oder dessen derzeitigen Abhängikeiten im Wege steht, bricht pacman vorsichtshalber ab. Pacman guckt nicht zusätzlich, ob ein ebenfalls anstehenden Update von Paket B den Abhängikeitskonflikt von Paket A lösen würde. Jede Paketinstallation wird isoliert bewertet und durchgeführt, um die Gefahr eines inkonsistentes Systems zu minimieren.

Würde pacman berücksichtigen, dass die ebenfalls anstehende Installation/Aktualisierung von Paket B den Konflikt bei Paket A beseitigen würde und Paket A aktualisieren, würde es zu Problemen führen, wenn durch irgendwelche technischen Probleme der gesamte Aktualisierungprozess nicht komplett durchläuft und Paket B letzlich nicht aktualisiert wird. Dann hätte man einen Zustand, dass Paket A zwar aktualisiert ist, aber dessen Abhängkeiten nicht voll erfüllt sind.

Pacman versucht durch seine Funktionsweise schlicht dafür zu sorgen, dass das System nach jeder einzelnen Paketinstallation/-aktualisierung in sich konsistent bleibt.

 

[|Moppel|]

Meine Motivation von Win11 dauerhaft auf Cashy und co zu wechseln bekommt dann immer mal wieder einen Dämpfer.

Unter Windows wäre das Update halt durchgelaufen und z.B. dein Drucker hätte nicht mehr funktioniert.
Einer der Windows Klassiker.

Kann man sich jetzt überlegen, was man besser findet.

 

[mibbio]

Meine Motivation von Win11 dauerhaft auf Cashy und co zu wechseln bekommt dann immer mal wieder einen Dämpfer.

Ich sehe CachyOS ohnehin nicht unbedingt als geeignet für Umsteiger an, auch wenn es überall gerne als DAS Gaming-Linux für Jeden angepriesen wird. Es ist halt konzeptionell immer noch ein Arch Linux und Arch ist eben nicht für Einsteiger gedacht.

Es gibt genügend andere Distributionen, die deutlich besser für Einsteiger bzw. Umsteiger von Windows geeignet sind, also eine arch-basierte Distribution.

 

[Snakeeater]

Es ist kein Bug, sondern schlicht die gewollte Funktionsweise des Paketmanagers pacman. Bei der Installation einzelner oder auch mehrerer Pakete (Aktualisieren ist im Grunde auch ein (Drüber-)Installieren von Paketen), für jedes Paket einzeln, ob es sich unter Einhaltung der Abhängigkeit im aktuellen Systemzustand konfliktfrei installieren lässt.

Wenn dem irgendein anderes Paket aufgrund seiner derzeit installierten Version oder dessen derzeitigen Abhängikeiten im Wege steht, bricht pacman vorsichtshalber ab. Pacman guckt nicht zusätzlich, ob ein ebenfalls anstehenden Update von Paket B den Abhängikeitskonflikt von Paket A lösen würde. Jede Paketinstallation wird isoliert bewertet und durchgeführt, um die Gefahr eines inkonsistentes Systems zu minimieren.

Würde pacman berücksichtigen, dass die ebenfalls anstehende Installation/Aktualisierung von Paket B den Konflikt bei Paket A beseitigen würde und Paket A aktualisieren, würde es zu Problemen führen, wenn durch irgendwelche technischen Probleme der gesamte Aktualisierungprozess nicht komplett durchläuft und Paket B letzlich nicht aktualisiert wird. Dann hätte man einen Zustand, dass Paket A zwar aktualisiert ist, aber dessen Abhängkeiten nicht voll erfüllt sind.

Pacman versucht durch seine Funktionsweise schlicht dafür zu sorgen, dass das System nach jeder einzelnen Paketinstallation/-aktualisierung in sich konsistent bleibt.

Du beschreibst perfekt warum Pacman oder generell Paketmanagement absolut nicht auf dem aktuellsten Stand ist. Das ist doch absoluter Irrsinn ein Programm händisch zu deinstallieren nur um es danach neuzuinstallieren, wieso kann das Paketmanager einems das nicht abnehmen.

Deine Begründung warum er das nicht tut ist ein konstruiertes Szenario, der Packetmanager, könnte das Update des betroffenen Pakets auch einfach zurückstellen um Ende durchführen...

Edit:
Es ist tatsächlich pacman / Arch spezifisch, interessant.

Edit2:

Yes. Several package managers solve circular dependency issues through different approaches:

Atomic/Transactional Approach (similar to moss):

• Nix/NixOS and Guix: Functional package management where each package version coexists in an isolated store. Circular dependencies are avoided by building new versions with their exact dependencies, making old versions available until no longer referenced.

Sophisticated Dependency Solvers:

• APT/dpkg (Debian/Ubuntu): Plans entire transactions before execution, resolving circular dependencies by installing multiple packages in the correct order.
• DNF/Yum (Fedora/RHEL) and Zypper (openSUSE): Use the libsolv SAT solver, which can handle complex dependency chains including circular ones by finding a global solution.
• Portage (Gentoo): Uses a sophisticated resolver that can handle circular dependencies through its DAG-based system.
• conda: Employs a powerful solver capable of resolving circular dependency chains.
• Spack (HPC): Uses a DAG for dependency resolution, handling complex interdependencies.

Application-Level Isolation:

• Flatpak and Snap: Bundle dependencies with applications, eliminating system-level circular dependency issues.

The key distinction is that traditional solvers (APT, DNF, Zypper, Portage) resolve conflicts during planning, while functional managers (Nix, Guix, moss) avoid them through atomic, versioned stores.

 

[Knobi Wahn]

Es gibt genügend andere Distributionen, die deutlich besser für Einsteiger bzw. Umsteiger von Windows geeignet sind, also eine arch-basierte Distribution.

Da hänge ich mich kurz dran.

Dann also eher Bazzite oder Nobara und nicht Garuda oder Cachy, wenn ich den Schritt dann vollziehen möchte?

 

[mibbio]

könnte das Update des betroffenen Pakets auch einfach zurückstellen um Ende durchführen...

Ein Zurückstellen würde den Konflikt auch nicht lösen, da sich beide Paketupdates quasi aufgrund ihrer Versionsabhängigkeiten gegenseitig blockieren.

Der Konflikt sieht nämlich so aus:

• Protobuf ist aktuell in Version 35.0 installiert und soll auf 35.1 aktualisiert werden
• geht aber nicht, weil das aktuell installierte Paket von Mixx halt Protobuf in Version 35.0 haben will
• Protobuf aktualisieren würde die Bedingung für das aktuell installierten Mixx brechen
• jetzt stellen wir als Protobuf zurück, um erstmal Mixx zu aktualisieren
• Update von Mixx will aber Protobuf in Version 35.1, installiert ist aber noch 35.0 (da Protobuf-Update ja zurückgestellt)
• Mixx updaten geht also nicht, ohne vorher Protobuf zu aktualisieren

Durch diese wechselseitige Abhängigkeit zu unterschiedlichen Versionen des selben Paketes kann man also weder Protobuf vor Mixx aktualisieren, noch Mixx vor Protobuf.

Eine automatische Lösung wäre, alle so untereinander abhängige Pakete als atomare Operation gleichzeitig zu aktualisieren. Das würde aber die Programmlogik für das Paketmanagement komplexer (und potentiell fehleranfälliger machen). Arch Linux verfolgt allgemein (und damit auch bei Pacman) die Philosophie, möglichst auf Automatismen zu verzichten und wo sie nötig sind, die Automatismen möglichst einfach zu halten. Denn Arch will dem Nutzer möglichst viel Entscheidungfreiheit und Einflussmöglichkeit dahingehend lassen, was das System macht. Der Tradeoff ist dabei halt, dass man gelegentlich auch mal händisch korrigierend eingreifen muss.

Wer diesen Arch-Ansatz nicht mag, kann ja eine der vielen anderen Distributionen nehmen, die es anders machen.

 

[Moov]

Als Nvidia-Nutzer sollte man nervigere Bugs unter Windows gewohnt sein...
Wenn die Abhängigkeiten das gröößte Problem darstellt, gibt es hierfür gute Alternativen. Unter Fedora sollte es sowas etwa nicht geben, entsprechend auch auf Derivaten von Fedora, wie Bazzite. Jedes OS hat seine Quirks.
Immerhin gibt einem CachyOS mit, wo das Problem zu finden ist und dann kann man als User noch selbst entscheiden, ob man das fixen mag oder fürs erste ignoriert.

Win11 ist alles andere als ein rundes OS. Aus Gaming-Sicht habe ich allerdings kaum Störungen mit nvdia-Treibern. Erst Recht im Vergleich meiner Nutzungsdauer zu CashyOS oder. Auch Bazzite. Sehr ähnlich sind meine Linux Gehversuche mit AmD 9060xt verlaufen. Dennoch ist die Entwicklung div. Linux-Distributionen spannend und ich bleibe am Ball.

 

[JumpingCat]

Eine automatische Lösung wäre, alle so untereinander abhängige Pakete als atomare Operation gleichzeitig zu aktualisieren.

Das ist eigentlich die ganze normale Aufgabe vom Paketmanager. Der Zustand vor und nach dem Update soll konsistent sein. Dazwischen ist egal.

Ansonsten, ich nutze eine andere Distribution, Update die problematischen Pakete mit so was wie "ignore dependencies". Das kann man machen, wenn das nicht gerade Basispakete zum Booten / für den Paketmanager selbst sind.

 

[mibbio]

Das ist eigentlich die ganze normale Aufgabe vom Paketmanager. Der Zustand vor und nach dem Update soll konsistent sein. Dazwischen ist egal.

Und Pacman ist halt bewusst simpel gehalten. Dort wird ein inkonsistenes "dazwischen" einfach dadurch vermieden wird, dass jedes Paketupdate als eigenständiger Vorgang betrachtet wird.