Beiträge von Hidalgo

  • Konflikte beim Update von ffmpeg-7 via Myrlyn

    Ja - die URL ist entscheidend - das wusste ich auch, nur beim suchen nach den Unterschieden berücksichtigte ich das nicht.

    Mein Packman Repo hat die höchste eingestellte Prio, bisher lief der Befehl des möglichen Anbieterwechsels problemlos. Ist halt Gewohnheit - und natürlich kenne ich die Prioritäten des Users nicht und wenn es nicht so läuft, fragt der eben nochmal nach. Es geht wenigstens nichts kaputt - das wäre mir wirklich oberpeinlich!

  • Konflikte beim Update von ffmpeg-7 via Myrlyn

    Betrifft #21 und #22:

    Wenn du nicht abwarten willst bis der Bug behoben ist und du auch kein flatpak nutzen willst, dann würde ich aus den angebotenen Problemlösungen

    Lösung 3

    auswählen. Die betroffene Multimedia-Bibliothek wird dann vorerst auf dem alten Stand belassen. Das System bleibt stabil, und das restliche Update sollte durchlaufen.

    Mit Lösung 3 umgehst du das fehlerhafte Update elegant und dein restliches System wird aktualisiert - digiKam kannst du wie gewohnt weiterbenützen.

    Nach ein paar Tagen, wenn der Bug in den openSUSE-Repositories behoben wurde, läuft das nächste zypper dup dann ganz ohne Konflikte durch.

    Warum das bei Sauerland läuft? (bp160.1.4)
    Schaue dir die Versionsnummern ganz genau an:

    • Bei dir (Fehlermeldung): libdigikamcore8_7_0-8.7.0-bp160.1.3.x86_64
    • Bei Sauerland: libdigikamcore8_7_0-8.7.0-bp160.1.4.x86_64

    Der feine Unterschied liegt am Ende: .1.4 statt .1.3.

    Das bedeutet, dass in dem Repository von sauerland (OSS-DO-org) der Bug bereits behoben wurde. Die Maintainer haben digiKam dort neu gegen das neue FFmpeg-7 gebaut, wodurch die Abhängigkeiten bei ihm fehlerfrei auflösen.

    Er nutzt ein anderes Repository (OSS-DO-org). Dieses Repository war beim Synchronisieren der neuen Pakete einfach schneller als das Repository, das dein System aktuell abfragt.

    Das bringt mich auf eine Idee:

    Zwingen zypper dazu, die Repository-Indizes komplett frisch vom Hauptserver zu laden, anstatt lokale Caches zu nutzen:

    Code
    sudo zypper ref -f
sudo zypper dup --allow-vendor-change

    Falls die Version .1.4 nun auch bei dir auftaucht, verschwindet die Fehlermeldung sofort und das Update läuft ohne Konflikt durch wie bei sauerland.

    Ansonsten: Lösung 3.

  • OpenSUSE Leap 16.0 Neuinstallation funktioniert bis auf Sound-Ausgabe über Lautsprecher

    Soundkarten-Treiber müssen extrem früh beim Booten geladen werden und befinden sich standardmäßig innerhalb eines Mini-Start-Abbilds. Der Kernel weiß aber noch gar nichts vom neuen Abbild - der lädt noch das alte.

    Darum würde ich in der Konsole:

    Code
    sudo dracut -f --regenerate-all

    durchführen und somit ein neues Abbild generieren (mit deinem neuen Intel-Treiber) und danach einen Neustart machen.

    Falls dann immer noch kein Ton kommt ... aber das werden wir ja sehen.

    Nach Eingabe des obigen Befehls und "Return" bitte warten bis dein Benutzername wieder da steht. Das Ganze kann länger dauern, muss es aber nicht. Wenn Text durchläuft oder auch einfach nur der Cursor blinkt - das ist alles normal.

    Manche Linux-Distributionen haben Hintergrund-Dienste, die frisch installierte Firmware nach ein paar Minuten oder beim Herunterfahren automatisch in das Start-Paket integrieren. Da Leap 16.0 aber brandneu ist und auf einer neuen Architektur (ALP) basiert, würde ich mich nicht darauf verlassen.

  • Konflikte beim Update von ffmpeg-7 via Myrlyn

    Hallo Sauerland,

    danke für die Klarstellung! Da hatte ich die ursprünglichen Konzept-Pläne zur ALP-Codebasis (Trennung von Basis und App-Layer) wohl fälschlicherweise eins zu eins auf das finale Leap 16 projiziert. Du hast völlig recht: Es ist ein klassisches RPM-System geblieben und man kann DigiKam weiterhin normal über die Repositories (wie KDE-Extra) beziehen.

    Mein radikaler Wechsel auf das Flatpak war aus der Not geboren, um der 'Dependency Hell' mit den ffmpeg- und Packman-Bibliotheken auszuweichen. Da das Flatpak alle Multimedia-Codecs isoliert mitbringt, läuft DigiKam bei mir jetzt absolut stressfrei und die Paketkonflikte bei zypper dup sind Geschichte.

    Danke dir für das Geraderücken der Fakten – wieder was gelernt!

    Für mich bleibt das Flatpak in diesem Fall trotzdem die bequemere Lösung, um das Basissystem sauber zu halten.

    Ich sah dieses Vorgehen auch als zukunftsfest an. Große Systeme wie das Steam Deck (SteamOS) setzen bei Desktop-Apps ja bereits exakt auf diese Trennung via Flatpak, und auch bei Fedora (mit den Atomic-Versionen) oder Linux Mint ist Flatpak fest als moderner Standard integriert. Da diese Pakete völlig unabhängig von der genutzten Distribution laufen, bieten sie bei solchen Multimedia-Konflikten langfristig eine enorme Stabilität.

  • Konflikte beim Update von ffmpeg-7 via Myrlyn

    Das Problem hatte ich auch. Probleme mit digikam was gelöscht werden sollte im Zusammenhang mit ffmpeg.

    War allerdings auch voraussehbar, denn:
    Leap 16 basiert auf der neuen Alp-Codebasis (Adaptable Linux Platform). Das System trennt das minimale, stabile Basissystem strikt von den Anwendungen. Große Desktop-Programme wie DigiKam werden nun standardmäßig über Flatpak bereitgestellt, um solche Abhängigkeitskonflikte (Dependency Hell) mit Systembibliotheken wie ffmpeg/libavfilter dauerhaft zu vermeiden.

    Das ist nun mal so, wenn man kein Windows verwendet. Leap 16 stellt ein an Linux Enterprise angelehntes sehr stabiles Minimalsystem zur Verfügung. Anwendungen werden - wie meines Wissens auch bei einigen anderen Distributionen - über Flatpak bereitgestellt. "Susi" kümmert sich - mit Ausnahmen - nicht mehr um die Anwendungen und die entsprechenden alten Suse-Quellen sind dann veraltet. Letztere werden bei Upgrades aber mitgeschleppt, Systembibliotheken werden erneuert hinsichtlich des Basissystems und schon gibt es Konflikte: Das Eine bremst das Andere aus.

    Davon kann man halten was man will - ich finde das gut, denn Stabilität des Basissystems hat bei mir oberste Prämisse!

    Ich habe eigentlich gar nicht viel nachgedacht, sondern rigoros den alten Mist deinstalliert und dgikam von flatpak installiert:


    Code
    sudo zypper rm digikam libdigikamcore8_7_0
    Code
    flatpak install flathub org.kde.digikam

    Fertig.

    ffmpeg ist bei mir so:


    digikam läuft, ffmpeg läuft ... was will ich mehr.

    Flatpak hat Vor und Nachteile - wie das eben bei Allem nun mal der Fall ist - siehe Netz. Für mich überwiegen Vorteile.

  • zypper dup löscht externe Pakete: Bug or Feature ?

    Also wird nicht nachgefragt durch zypper-dup, ob das Programm gelöscht werden soll wenn es verwaist ist.
    In dem Falle also den "Daumen hoch" unter #2 bitte entfernen, weil ich dann ja falsch lag - warum ich nach wie vor anderer Meinung bin, steht unter dem Zitat zu meiner Antwort darauf das zypper-dup "in diesem Fall" doch nachfragt. Ich wollte in diesem Forum nur nicht so sehr ins Eingemachte gehen - nun führe ich das weiter unten aus:

    Zitat von Sauerland

    Genau das passiert bei zypper dup nicht.


    Code
    zypper se -si | grep -i systempak
i  | libdigikamcore9_1_0                          | Paket   | 9.1.0-lp160.274.1                                    | x86_64 | (Systempakete)
i+ | libstdc++33-32bit                            | Paket   | 3.3.3-42.1                                           | x86_64 | (Systempakete)
i+ | r8168-kmp-default                            | Paket   | 8.056.02_k6.12.0_160000.34-lp160.73.8                | x86_64 | (Systempakete)
i+ | r8168-kmp-default                            | Paket   | 8.056.02_k6.12.0_160000.33-lp160.73.7                | x86_64 | (Systempakete)

    Zypper dup fragt "normalerweise" bei verwaisten Programmen nicht nach. Das macht i.d.R. ja auch keinen Sinn bei einem Distributions-Upgrade. Das verwaiste Programm bleibt einfach auf der Platte.
    Bei "RStudio" (das als lokales/verwaistes Paket gilt) fragt "Zypper-dup" nach meinem Verständnis aber nach,weil die OpenSuSE Paketverwaltung zwischen


    1. Harmlos verwaist


    und


    2. Blockierend verwaist


    unterscheidet.

    Wenn ein Programm in den den Repositories nicht mehr zu finden ist, dessen Abhängigkeiten (Bibliotheken) aber weiterhin unverändert im System vorhanden sind, verhält sich zypper dup standardmäßig passiv. Das Programm bleibt einfach installiert und Zypper ignoriert es beim Upgrade schlichtweg. Es gibt keine Nachfrage. Das ist wohl die Regel.


    Bei Bei RStudio kommt aber eben doch die Nachfrage ins Spiel, weil das Paket eine Abhängigkeits-Kette blockiert, denn das Fedora RPM "RStudio" verlangt nach ganz bestimmten Systembibliotheken. "Rstudio" von Fedora stellt sich dann quer, wenn Opensuse bei einem Upgrade diese Bibliotheken verändern will oder entfernen, um das System sauber zu halten. Damit gerät nun der Paketmanager ins Dilemma: Zypper-dup stoppt den Prozess und fragt interaktiv nach, wie man das Problem lösen möchte, z.B. RStudio löschen, Abhängigkeiten ignorieren oder das Update der Bibliotheken abbrechen.

    Nochmal ein Versuch, es einfacher zu erklären was ich meine:

    Ein reines "Dasein" als verwaistes Paket reicht für eine Nachfrage bei zypper dup nicht aus – es muss erst zu einem handfesten Konflikt mit neueren Systemdateien kommen. Da RStudio sehr eng mit dem System verzahnt ist, triggert es diese Nachfrage - und es gibt eben eine ebensolche an den User.

    Ein gesetzter Sperrauftrag (Lock) tarnt das Paket nun quasi vor dem Paketmanager, sodass Zypper weiß, dass es diese Abhängigkeit um jeden Preis unangetastet lassen soll.


    Das ist mein Verständnis zu diesem Problem gewesen, weshalb ich Post #2 abschickte. Wenn es nicht so ist, wie ich es oben beschrieb, dann fehlt mir irgendwie jede Logik für die Beobachtung des Fragestellers zu "rstudio" und allen Programmen, die ebensolche Problematik für den Paketmanager darstellen - auch wenn das eher die Ausnahme ist.


    Falsch? Oder richtig?