Hallo,
wollte heute wieder ein Update mit Pacman machen, da kommt folgende Fehlermeldung:

[didi@PC-Buero ~]$ sudo pacman -Syu
:: Paketdatenbanken werden synchronisiert …
core ist aktuell
extra ist aktuell
multilib ist aktuell
:: Vollständige Systemaktualisierung wird gestartet …
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 icu (75.1-1) verletzt Abhängigkeit »libicui18n.so=74-64«, benötigt von electron22
:: Installation von icu (75.1-1) verletzt Abhängigkeit »libicuuc.so=74-64«, benötigt von electron22
:: Installation von icu (75.1-1) verletzt Abhängigkeit »libicui18n.so=74-64«, benötigt von electron25
:: Installation von icu (75.1-1) verletzt Abhängigkeit »libicuuc.so=74-64«, benötigt von electron25
:: Installation von icu (75.1-1) verletzt Abhängigkeit »libicuuc.so=74-64«, benötigt von qt5-webkit
:: Installation von icu (75.1-1) verletzt Abhängigkeit »libicui18n.so=74-64«, benötigt von qt5-webkit

Was kann ich da tun?

Viele Grüße
Dietmar

electron22, electron25 und qt5-webkit sind keine Pakete aus dem offiziellen Repo, sondern dem AUR, für dessen Aktualisierung du selber verantwortlich bist.
Indem du diese Pakete entfernst, wird das Systemaupdate wieder möglich sein. Als nächstes müsstest du überprüfen, weiche dieser Pakete du davon tatsächlich benötigst. Von electron gibt es neuere Versionen im offiziellen Repo, das kannst du installieren, falls nicht zwingend eine der EOL-Versionen benötigt wird.
Für qt5-webkit wird es reichen, das Paket neu gegen die aktuellen Bibliotheken zu bauen (bei Problemen siehe Kommentare im AUR).

    Martin-MS electron22, electron25 und qt5-webkit sind keine Pakete aus dem offiziellen Repo, sondern dem AUR

    Das muß nicht sein, es können genauso gut auch "übriggebliebene" Abhängigkeiten sein, gerade die diversen electronXX Pakete hatte ich auch (nebst anderem).

    Eine gute Möglichkeit das zu finden ist:
    pacman -Qdt
    Das zeigt alle als Abhängigkeit installierten Pakete an, die aber von nichts mehr benötigt werden. Diese Liste kann sehr "lang" sein, und sollte auch penibel kontrolliert werden ob nicht doch ein benötigtes Paket dabei ist.
    Z.B. ich hatte irgendwann 2020 irgendwas installiert was inkscape als Abhängigkeit mitzog. Beim "Aufräumen" mittels obiger Liste sah ich das und habe es dann als explizit installiert in der Datenbank markiert.
    Penibel kontrollieren z.B. mit:
    pacman -Qdti | less
    Alle gefundenen nicht benötigten Abhängigkeiten deinstallieren geht dann mit:
    pacman -Qdtq | pacman -Rns -
    (Danach kann es natürlich weitere jetzt nicht mehr nötige Abhängigkeiten geben, also ggf. nochmal prüfen).

    • Dirk hat auf diesen Beitrag geantwortet.

      GerBra pacman -Qdtq | pacman -Rns -
      (Danach kann es natürlich weitere jetzt nicht mehr nötige Abhängigkeiten geben, also ggf. nochmal prüfen).

      Und natürlich auch Programme, die du noch verwenden willst, und die eigentlich gar keine „echten“ Abhängigkeiten sind.

      Blind sollte man diesen Befehl also so oder so nicht ausführen.

        Martin-MS electron22, electron25 und qt5-webkit sind keine Pakete aus dem offiziellen Repo, sondern dem AUR, für dessen Aktualisierung du selber verantwortlich bist.

        Das seh ich nicht so. Die electron-Pakete (mehrere!) kommen beispielsweise mit Microsoft Visual Studio Code. Das AUR war auf meiner Maschine daran nie beteiligt. Und wenn diese Anhängigkeiten von mir mit pacman installiert wurden, erwarte ich zumindest, dass sie auch von pacman am update-Prozess beteiligt werden.

        • Martin-MS hat auf diesen Beitrag geantwortet.

          T.M. Das seh ich nicht so. Die electron-Pakete (mehrere!) kommen beispielsweise mit Microsoft Visual Studio Code. Das AUR war auf meiner Maschine daran nie beteiligt.

          Zum Zeitpunkt der Installation war das vielleicht so, aber heute nicht mehr. In den Kommentaren wird auch auf diesen Umstand hingewiesen:

          Check if you still need this. It is in the AUR because it is EOL and removed from Arch official repos since no official packages depend on it.

          Es ist gängige Praxis, dass Pakete aus den offiziellen Repos entweder ganz verschwinden, oder in das AUR verschoben werden. Es mag sein, dass seinerzeit bei der Installation von code eine Abhängigkeit zu beispielsweise electron22 bestand, das ist aber heute nicht mehr so, sondern es ist von electron28 abhängig.

          Die Tatsache, dass bei Dietmar mehr als ein electron-Paket installiert ist lässt die Vermutung zu, dass mit der Zeit über die Abhängigkeiten jeweils das zu der Zeit aktuelle Paket installiert wurde, wahrscheinlich wird auch electron28 dabei sein so dass die veralteten Pakete entbehrlich sein dürften.

          T.M. Und wenn diese Anhängigkeiten von mir mit pacman installiert wurden, erwarte ich zumindest, dass sie auch von pacman am update-Prozess beteiligt werden.

          Das ist eine falsche Erwartungshaltung. pacman verwaltet nur Aktualisierungen für Pakete aus den hinterlegten Installationquellen, und wenn ein Paket wie gesehen aus dem offiziellen Repo fällt, dann ist es der Paketverwaltung zwar noch bekannt, wird aber von pacman als manuell installiertes Paket behandelt, für dessen Aktualisierung es nicht mehr zuständig sein kann.

          Welche Pakete davon betroffen sind, kannst du dir mit pacman -Qm berichten lassen. Diese Pakete sind aus Gründen nicht (mehr) im Bestand der offiziellen Repos, und um die Aktualisierung musst du dich fortan selber kümmern.

          • T.M. hat auf diesen Beitrag geantwortet.

            Dirk Blind sollte man diesen Befehl also so oder so nicht ausführen.

            Deswegen schrieb ich ja extra (zweimal) penibel kontrollieren. Wie alles, was man irgendwie an ein "pacman -R" pipen will/muß.
            Meine Installation ist von 2015, irgendwann 2022 hatten sich über die Zeit bei mir rund 120 Pakete angesammelt die über -Qdt gefunden wurden. Das war eine lange Liste zum durchsehen.
            Mittlerweile habe ich dieses "-Qdt | wc -l" in einem Checkskript mit drin, und achte so darauf das die Anzahl nicht mehr so "hoch" wird, greife also früher ein.

            Ich bin mit einem pacman -Rsn $(pacman -Qdtq) nicht ganz so penibel.
            Die Arch Repositorien rollen und mein System ist aktuell. Da gibt es nichts zu konservieren schon gar nicht ehemalige Abhängigkeiten und wenn dadurch tatsächlich mal etwas fehlen sollte, dann werde ich das schon irgendwann mitbekommen und es ggf. mit einen pacman -S xxx genau so schnell wieder aufgespielt haben.
            Das ist ja der Vorteil davon, wenn man sein System selbst zusammengestellt hat. Man weiß was man braucht.
            Zugegeben, ich überfliege auch kurz die Ausgabe von pacman -Qdtq bevor ich das mache. 😉
            Aber eine gesteigerte Vorsicht halte ich dabei kaum für angemessen.

            • Martin-MS hat auf diesen Beitrag geantwortet.

              tuxnix Aber eine gesteigerte Vorsicht halte ich dabei kaum für angemessen.

              Ich auch nicht.

              Die Situation entsteht eigentlich nur dann, wenn eine Abhängigkeit seitens der Paketbetreuer geändert, oder das Paket ganz aus den offiziellen Repos entfernt wird. Das war zB kürzlich der Fall, als der Wechsel von Plasma 5 auf Plasma 6 anstand. Da sind jede Menge Qt5-Pakete aus den Repos gefallen, haben aber auch gefühlt genau so viel verwaiste Pakete zurück gelassen, die mal als Abhängigkeit installiert wurden, jetzt aber nicht mehr benötigt werden. Die Liste war so umfangreich, dass ich da nicht mehr jedes einzelne Paket überprüfen konnte, ob ich es wirklich noch gebrauche. Bei den meisten wusste ich nicht einmal, was sie genau machen und wofür sie mal gut waren.

              Dass man sich um solche verwaisten Pakete durchaus kümmern muss, zeigt ja auch der Fall von Dietmar, bei dem noch das Paket qt5-webkit installiert ist, das wahrscheinlich von nichts mehr benötigt und einfach zurück geblieben ist, aber jetzt Probleme macht, weil es nicht mehr in eine aktuelle Systemumgebung passt. Der Verbleib solcher Pakete im System kann eine Zeit lang gut gehen, fällt einem aber irgendwann auf die Füße.

              Martin-MS Die Tatsache, dass bei Dietmar mehr als ein electron-Paket installiert ist lässt die Vermutung zu, dass mit der Zeit über die Abhängigkeiten jeweils das zu der Zeit aktuelle Paket installiert wurde, wahrscheinlich wird auch electron28 dabei sein so dass die veralteten Pakete entbehrlich sein dürften.

              Das war immer so, wahrscheinlich bei Vielen. Und diese nebeneinander installierten electrons bekamen auch noch updates, auch die älteren. Ich bin bisher davon ausgegangen, dass die aufeinander aufbauen und gemeinsam nötig sind (nicht schlau, aber denkbar).

              Ich habe jetzt bei mir electron25 und electron27 uninstalliert, danach gelingt das update und code läuft tatsächlich einwandfrei allein mit electron28. Danke für den Hinweis. Und dies ist mein einziges Programm auf electron-Basis.

              Aber richtig sauber ist das nicht. Und daß ein Paket allein deshalb, weil noch eine alte Version eines anderen herumliegt, kein update bekommen kann, ist auch nicht gut. Diese Bibliotheken (also .a und .so) müßten doch eigentlich versioniert sein und nebeneinander liegen und so auch benutzt (oder eben ignoriert) werden können.

              • Martin-MS hat auf diesen Beitrag geantwortet.

                T.M. Aber richtig sauber ist das nicht. Und daß ein Paket allein deshalb, weil noch eine alte Version eines anderen herumliegt, kein update bekommen kann, ist auch nicht gut. Diese Bibliotheken (also .a und .so) müßten doch eigentlich versioniert sein und nebeneinander liegen und so auch benutzt (oder eben ignoriert) werden können.

                Ich kenne electron nicht im Detail und weiß deshalb auch nicht, warum es davon so viele unterschiedliche Versionen geben muss; wahrscheinlich aus Kompatibilitätsgründen, wie wir es auch von Java gewohnt sind.
                Es gibt aktuell von electron in den offiziellen Repos die Versionen 23, 27, 28, 29 und 30 was zeigt, dass sie durchaus auch parallel installiert werden können.

                Das Problem ist ja auch nicht deswegen entstanden, weil electron25 parallel mit anderen Versionen installiert war, sondern das Paket nicht gegen die Bibliotheken von ICU 75 gebaut wurde und deshalb noch nach der Version 74 verlangte, die es aber in einer aktuellen Systemumgebung nicht mehr gibt. Darum brach das Updare ab, weil die Abhängigkeiten sonst verletzt worden wären.

                Für die in den offiziellen Repos befindlichen Versionen erledigen das die Maintainer, deswegen funktionieren sie noch. Für die aus den Repos entfernten Versionen muss das aber der Benutzer selber machen. Wenn du also wirklich electron25 noch benötigst, dann müsstest du es selber neu bauen, und dann würde es auch wieder in einer aktuellen Systemumgebung mit den anderen Versionen parallel zu installieren sein.