Wie kann ich das Update beenden?
Beenden geht nicht, nur abbrechen, Platz schaffen.
Poste mal:
lsblk -o NAME,UUID,PARTTYPE,MOUNTPOINT,PARTUUID,FSTYPE,FSSIZE,FSUSED,MOUNTPOINTinstalling package Mesa-libva-26.1.4-1699.2.pm.1.x86_64 needs 240KB more space on the / filesystem
/ Partition voll.......
War ja auch keine Kritik, war nur ein Einwurf ...
Das konntest du aber mit deinen Befehlen nicht zeigen......
Denn in diesem Beitrag geht es explizit um ffmpeg-7 und nicht ffmpeg-8
Und noch einmal:
die ffmpeg-8 wirst du bei Leap 16.0 nur von Packman bekommen, Leap bietet keine neueren Versionen.
Ich schätze einmal, ffmpeg-8 wird es in Leap 16.0 nicht im OSS Repo geben.........
Ist auch unnötig, die anderen Versionen funktionieren ja.....
Und jetzt nicht rausreden mit: Ja ist nur im Packman..........
Packman? Welcher Packman?
Du weißt ganz genau, was ich damit sagen wollte...........
Und genau das ist eingetreten......
Und Tumbleweed hat sogar noch ffmpeg-4
| ffmpeg-4 | Paket | 4.4.8-1.1 | x86_64 | openSUSE-Tumbleweed-OssMensch ist das alt.......
Leap hängt ganz schön hinterher ...
Du solltest aber schon wissen, was die Befehle machen........
stephan@linux64:~> zypper se -si ffmpeg-8
Repository-Daten werden geladen...
Installierte Pakete werden gelesen...
Keine passenden Objekte gefunden.
Hinweis: Für eine erweiterte Suche inkl. nicht momentan aktivierter Remote-Ressourcen bitte
'zypper search-packages' verwenden.
stephan@linux64:~> stephan@linux64:~> 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_Goettingen
| ffmpeg-8 | Quellpaket | 8.1.2-160000.3.1 | noarch | Packman_Goettingen
| ffmpeg-8-debuginfo | Paket | 8.1.2-160000.3.1 | x86_64 | Packman_Goettingen
| ffmpeg-8-debugsource | Paket | 8.1.2-160000.3.1 | x86_64 | Packman_Goettingen
| ffmpeg-8-libavcodec-devel | Paket | 8.1.2-160000.3.1 | x86_64 | Packman_Goettingen
| ffmpeg-8-libavdevice-devel | Paket | 8.1.2-160000.3.1 | x86_64 | Packman_Goettingen
| ffmpeg-8-libavfilter-devel | Paket | 8.1.2-160000.3.1 | x86_64 | Packman_Goettingen
| ffmpeg-8-libavformat-devel | Paket | 8.1.2-160000.3.1 | x86_64 | Packman_Goettingen
| ffmpeg-8-libavutil-devel | Paket | 8.1.2-160000.3.1 | x86_64 | Packman_Goettingen
| ffmpeg-8-libswresample-devel | Paket | 8.1.2-160000.3.1 | x86_64 | Packman_Goettingen
| ffmpeg-8-libswscale-devel | Paket | 8.1.2-160000.3.1 | x86_64 | Packman_Goettingen
Hinweis: Für eine erweiterte Suche inkl. nicht momentan aktivierter Remote-Ressourcen bitte
'zypper search-packages' verwenden.
stephan@linux64:~> Und jetzt nicht rausreden mit: Ja ist nur im Packman..........
Siehe auch das traurige Smiley in Myrlyn:
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.
Ganz genau.
Wenn kein Problem da ist, bleibt es so wie es ist, wenn es aber Abhängigkeitskonflikte gibt, fragt zypper (normalerweise) mit Lösungsmöglichkeiten nach.
Bei mir z.B. libstdc++33-32bit (wg. anderem Beitrag installiert), die keine Probleme bereitet und daher auch nicht angetastet ist.
