Konflikte beim Update von ffmpeg-7 via Myrlyn

Ich denke das wird hier ein ähnliches Problem sein:

zypper dup --allow-vendor-change
[sudo] Passwort für root: 
Dienst 'openSUSE' wird aktualisiert.
Repository-Daten werden geladen...
Installierte Pakete werden gelesen...
Warnung: Sie sind im Begriff, eine Distributionsaktualisierung mit allen aktivierten Repositorys durchzuführen. Vergewissern Sie sich, dass diese Repositorys kompatibel sind, bevor Sie fortfahren. Weitere Informationen zu diesem Kommando finden Sie unter 'man zypper'.
Distributions-Aktualisierungen werden verarbeitet...

Problem: 1: das installierte libdigikamcore8_7_0-8.7.0-bp160.1.3.x86_64 erfordert 'libavfilter.so.10(LIBAVFILTER_10.4_SUSE)(64bit)', aber diese Anforderung kann nicht bereitgestellt werden
Gelöschte Anbieter: libavfilter10-7.1.2-160000.3.2.x86_64
Nicht installierbare Anbieter: libavfilter10-7.1.1-160000.2.2.x86_64[openSUSE:repo-oss]
                   libavfilter10-7.1.2-160000.1.1.x86_64[openSUSE:repo-oss]

 Lösung 1: Folgende Aktionen werden ausgeführt:
  Deinstallation von libdigikamcore8_7_0-8.7.0-bp160.1.3.x86_64
  Deinstallation von ffmpegthumbs-kf5-25.04.3-bp160.1.2.x86_64
 Lösung 2: Deinstallation von libdigikamcore9_1_0-9.1.0-lp160.274.1.x86_64
 Lösung 3: veraltetes libdigikamcore9_1_0-9.1.0-lp160.274.1.x86_64 beibehalten
 Lösung 4: libdigikamcore8_7_0-8.7.0-bp160.1.3.x86_64 durch Ignorieren einiger Abhängigkeiten brechen

Wählen Sie aus den obigen Lösungen mittels Nummer oder brechen Sie (a)b [1/2/3/4/a/d/?] (a):

Je nach ausgewählter Lösung kommen dann weitere Fehlermeldungen.

DigiKam möchte ich eigentlich schon behalten...

Zitat von Omegator

Problem: 1: das installierte libdigikamcore8_7_0-8.7.0-bp160.1.3.x86_64 erfordert 'libavfilter.so.10(LIBAVFILTER_10.4_SUSE)(64bit)', aber diese Anforderung kann nicht bereitgestellt werden Gelöschte Anbieter: libavfilter10-7.1.2-160000.3.2.x86_64

Ja, das ist der bereits genannte bug, also abwarten ...

1270272 – A message is displayed while updating.

Vielen Dank Luigi,

dann warten wir mal ab...

Bin ich schon zu spät für die Party?

ich hatte mit dem ffmpeg-7 Update auch so meine Konflikte...

Bei meiner Konfiguration lag es letztendlich am Paket "ffmpegthumbnailer".

Jetzt hab ich nur keine Videothumbnails mehr aber das ist Verkraftbar bis ein fix kommt.

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:

sudo zypper rm digikam libdigikamcore8_7_0

flatpak install flathub org.kde.digikam

Fertig.

ffmpeg ist bei mir so:

zypper se -s ffmpeg-8

Repository-Daten werden geladen...
Installierte Pakete werden gelesen...

S  | Name                         | Type       | Version          | Arch   | Repository
---+------------------------------+------------+------------------+--------+-----------
   | ffmpeg-8                     | Paket      | 8.1.2-160000.3.1 | x86_64 | Packman
   | ffmpeg-8                     | Quellpaket | 8.1.2-160000.3.1 | noarch | Packman
   | ffmpeg-8-debuginfo           | Paket      | 8.1.2-160000.3.1 | x86_64 | Packman
   | ffmpeg-8-debugsource         | Paket      | 8.1.2-160000.3.1 | x86_64 | Packman
   | ffmpeg-8-libavcodec-devel    | Paket      | 8.1.2-160000.3.1 | x86_64 | Packman
   | ffmpeg-8-libavdevice-devel   | Paket      | 8.1.2-160000.3.1 | x86_64 | Packman
   | ffmpeg-8-libavfilter-devel   | Paket      | 8.1.2-160000.3.1 | x86_64 | Packman
   | ffmpeg-8-libavformat-devel   | Paket      | 8.1.2-160000.3.1 | x86_64 | Packman
   | ffmpeg-8-libavutil-devel     | Paket      | 8.1.2-160000.3.1 | x86_64 | Packman
   | ffmpeg-8-libswresample-devel | Paket      | 8.1.2-160000.3.1 | x86_64 | Packman
   | ffmpeg-8-libswscale-devel    | Paket      | 8.1.2-160000.3.1 | x86_64 | Packman

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.

Zitat von Hidalgo

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:

Äh mal ne Frage:

Hab ich hier etwas verpasst oder warum ist mein System noch immer so wie vorher oder auch Tumbleweed ist?

Spaß beiseite, @Hildlago:

Leap 16.0 ist nicht immutable und auch werden standardmäßig keine flatpacks benutzt. Man kann immer noch alles ohne Probleme mit Leap 16.0 anstellen, selbst das System zerstören......

Flatpacks kann man über discover oder per Kommandozeile installieren, bei mir kommt digikam aber aus einem Repo:

zypper se -s digikam
Repository-Daten werden geladen...
Installierte Pakete werden gelesen...

S  | Name                          | Type       | Version                  | Arch   | Repository
---+-------------------------------+------------+--------------------------+--------+-----------
i+ | digikam                       | Paket      | 9.1.0-lp160.274.3        | x86_64 | KDE-Extra
v  | digikam                       | Paket      | 8.7.0-bp160.1.3          | x86_64 | OSS-DO-org

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.

Gibt es denn jetzt eine Lösung, oder geht das nur mit dem Umstieg auf Flatpak?

Zitat von Omegator

Gibt es denn jetzt eine Lösung, oder geht das nur mit dem Umstieg auf Flatpak?

Bei mir gibt es keine Probleme:

linux64:/home/stephan # zypper in -f libdigikamcore
libdigikamcore8_7_0            libdigikamcore9_1_0            libdigikamcore9_1_0-debuginfo
linux64:/home/stephan # zypper in -f libdigikamcore8_7_0 
Repository-Daten werden geladen...
Installierte Pakete werden gelesen...
Installation von 'libdigikamcore8_7_0-8.7.0-bp160.1.4.x86_64' aus Repository 'OSS-DO-org' wird erzwungen.
Paketabhängigkeiten werden aufgelöst...

Das folgende NEUE Paket wird installiert:
  libdigikamcore8_7_0

1 neues Paket zu installieren.

Paketgröße zum Herunterladen:     9,2 MiB

Änderung der Installationsgröße des Pakets:
              |      30,8 MiB  erforderlich für Pakete, die installiert werden sollen
    30,8 MiB  |  -      0 B    freigegeben von Paketen, die entfernt werden sollen

Backend:  classic_rpmtrans
Fortfahren? [j/n/v/...? zeigt alle Optionen] (j): 
Vorladen: libdigikamcore8_7_0-8.7.0-bp160.1.4.x86_64.rpm [fertig]
Vorladen abgeschlossen. [Erfolg (4,8 MiB/s) ] ...............................................................[fertig]
Abrufen: libdigikamcore8_7_0-8.7.0-bp160.1.4.x86_64 (OSS-DO-org)                                 (1/1),   9,2 MiB    

Überprüfung auf Dateikonflikte läuft: .......................................................................[fertig]
(1/1) Installieren: libdigikamcore8_7_0-8.7.0-bp160.1.4.x86_64 ..............................................[fertig]
Nach-Transaktions-Skripte werden ausgeführt .................................................................[fertig]
linux64:/home/stephan # 

Hier das Update:

Die folgenden 64 Pakete werden aktualisiert:
  ffmpeg-6-libavcodec-devel ffmpeg-6-libavdevice-devel ffmpeg-6-libavfilter-devel ffmpeg-6-libavformat-devel
  ffmpeg-6-libavutil-devel ffmpeg-6-libpostproc-devel ffmpeg-6-libswresample-devel ffmpeg-6-libswscale-devel ffmpeg-7
  gimp gimp-lang gimp-plugin-aa gimp-plugin-python3 handbrake-gtk handbrake-gtk-lang libavcodec57 libavcodec58_134
  libavcodec60 libavcodec61 libavdevice57 libavdevice58_13 libavdevice60 libavdevice61 libavfilter10 libavfilter6
  libavfilter7_110 libavfilter9 libavformat57 libavformat58_76 libavformat60 libavformat61 libavresample3
  libavresample4_0 libavutil55 libavutil56_70 libavutil58 libavutil59 libgimp-3_0-0 libgimpui-3_0-0 libhdr10plus-4_1
  libpostproc54 libpostproc55_9 libpostproc57 libpostproc58 libpython2_7-1_0 libswresample2 libswresample3_9
  libswresample4 libswresample5 libswscale4 libswscale5_9 libswscale7 libswscale8 libx264-165 libx264-devel
  libx265-215 libx265-devel nvidia-open-driver-G07-signed-kmp-default python-base r8152-udev-rules r8152-ueficert
  r8168-blacklist-r8169 r8168-ueficert x265

ffmpeg-6 und ffmpeg-7 ohne Probleme, aber von Packman.

Funktioniert bei mir leider nicht, führt zu Fehlermeldungen.

ffmpeg ist bei mir auch von Packman.