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

Zitat von rkbwde

Und die Deinstallation von rstudio hatte ich ja gecancelt, daher steht wohl auch nichts im Log ...

Da hast du genau geschaut????Oder mal den lock auf rstudio entfernen und noch einmal ein Update machen, abbrechen und die ganze Fehlermeldung hier posten????

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?

Zitat von Hidalgo

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.

Zitat von Sauerland

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.

Danke - nun bin ich zufrieden.

Poste:

zypper se -si rstudio

Wenn zypper unter openSUSE Leap ein selbst gebautes RPM-Paket (das für Fedora gedacht war oder Fedora-Spezifikationen nutzt) „löscht“, meint das in der Regel, dass das Paket bei einem Systemupdate (zypper up oder zypper dup) deinstalliert oder durch ein anderes Paket ersetzt wird.

Dafür gibt es technische Gründe im RPM-Ökosystem:

Beispiel1

Ungelöste Abhängigkeitskonflikte (Dependency Hell)

Fedora und openSUSE benennen ihre Systembibliotheken oft unterschiedlich (z. B. heißt eine Bibliothek unter Fedora vielleicht openssl-libs, unter openSUSE aber libopenssl1_1).

Wenn ein reguläres Leap-Update neue Basis-Pakete einspielen muss, dein Fedora-RPM aber auf ganz bestimmten Versionen oder Namen beharrt, entsteht ein Konflikt. zypper entscheidet sich im Zweifel immer für die Stabilität des Basis-Systems und entfernt das störende Fremdpaket (das Fedora-RPM), um das Update der Systempakete durchführen zu können.

Beispiel2

Vendor-Richtlinien (Anbieterwechsel)

openSUSE nutzt ein striktes "Vendor"-Konzept. Ein Paket aus den offiziellen Quellen hat als Vendor openSUSE. Dein selbst gebautes Paket hat vermutlich einen anderen oder gar keinen Vendor-Eintrag.

Besonders wenn zypper dup (Distribution Upgrade) verwendet wird, versucht zypper, alle Pakete auf den offiziellen System-Vendor glattzuziehen. Fremdpakete werden dabei oft gnadenlos durch die offiziellen Versionen ersetzt oder bei Inkompatibilitäten entfernt.

Beispiel3

Obsoletes (Ersetzungen)

Es kann vorkommen, dass ein offizielles openSUSE-Paket in seinen Metadaten definiert, dass es das von dir gebaute Paket ("obsoletes") obsolet macht. Sobald zypper dieses openSUSE-Paket installiert, löscht es automatisch das Paket, das als veraltet deklariert wurde.

Was da bei dir schief läuft weißt nur du, da du das aus einem Fedora.rpm gebaut hast, wie du sagst. Warum du nicht das Programm aus dem Software-Download nutzt ...

https://software.opensuse.org/package/rstudio

Sollte man als Profi aber auch finden können