Hi zusammen!
Ich versuche grade openSUSE kennenzulernen, insbesondere zypper. eine Frage treibt mich dabei noch um:
Kann ich mit zypper ein Paket, nachdem ich es manuell installiert habe, nachträglich als abhängig installiert markieren? In allen anderen mir bekannten Paketmanagern (pacman, dnf, apt) gibt es diese Möglichkeit.
Der Hintergedanke ist ein Paket manuell zu installieren (z.B. gnome-shell), und dann später eine Gruppe/ein Pattern (z.B. gnome_x11) zu installieren welches dieses Paket als Abhängigkeit enthält. Das ursprünglich installierte Paket bleibt dann als User-Installed in der Liste hängen, das macht die Sache auf Dauer etwas unübersichtlich…
Das wird beim Bau des Paketes schon festgelegt.
Ich installiere rpms seit 1995. Deine Hintergedanken verstehe ich nicht. Unübersichtlich wurde es auch nie. Vielleicht gibst du dir etwas Mühe zu erläutern wovon du eigentlich redest. Ein Beispiel hilft mehr als viele Worte.
Hi! Erstmal danke für eure Antworten. Dass der Installationsgrund in der rpm steht kann ich mir kaum vorstellen… Zumal dnf auf RHEL/CentOS das kann 
Es geht um die Liste der installierten Pakete, ich suche aktuell meine selbst installierten Pakete/Patterns mit
zypper search -i | grep ^'i+'
Angenommen ich installiere gnome-terminal zur nutzung in einer anderen Umgebung, und danach gnome-x11 hängt gnome-terminal in dieser Liste rum. Oder andersrum, ich installiere Gnome, mag gnome-terminal will aber auf openbox o.ä. umsteigen. Dann löscht die Gnome Deinstallation auch das Terminal und ich muss es wieder installieren.
Es geht grundsätzlich darum ein sauberes, reproduzierbares System zu erstellen in dem keine Paketredundanzen entstehen.
Ich habe das natürlich vor dem Post auch schon intensiv gegooglet, und ich bin ehrlich erstaunt dass die Sinnhaftigkeit dieser Anwendung in fast jeder Antwort die ich gefunden habe in Frage gestellt wird. Alle namhaften Paketmanager die ich kenne können das selbstverständlich (apt-mark manual/auto, dnf mark [remove], pacman --asdep / --asexplicit), es scheint also genügend Leute zu geben, die das nutzen
Das sind evtl. Abhängigkeiten, die werden beim Bau eines rpms festgelegt.
Ich installiere gnome-terminal:
zypper in gnome-terminal
Repository-Daten werden geladen...
Installierte Pakete werden gelesen...
Paketabhängigkeiten werden aufgelöst...
Die folgenden 4 NEUEN Pakete werden installiert:
gnome-terminal gnome-terminal-lang libvte-2_91-0 vte-lang
4 neue Pakete zu installieren.
Gesamtgröße des Downloads: 1,7 MiB. Bereits im Cache gespeichert: 0 B. Nach der Operation werden
zusätzlich 9,4 MiB belegt.
Fortfahren? [j/n/v/...? zeigt alle Optionen] (j):
Paket libvte-2_91-0-0.58.3-1.32.x86_64 abrufen (1/4), 218,0 KiB (512,0 KiB entpackt)
Abrufen: libvte-2_91-0-0.58.3-1.32.x86_64.rpm ...................................................[fertig]
Paket vte-lang-0.58.3-1.32.noarch abrufen (2/4), 82,2 KiB (131,6 KiB entpackt)
Abrufen: vte-lang-0.58.3-1.32.noarch.rpm ........................................................[fertig]
Paket gnome-terminal-3.34.2-2.78.x86_64 abrufen (3/4), 656,9 KiB ( 3,1 MiB entpackt)
Abrufen: gnome-terminal-3.34.2-2.78.x86_64.rpm ......................................[fertig (3,5 MiB/s)]
Paket gnome-terminal-lang-3.34.2-2.78.noarch abrufen (4/4), 818,5 KiB ( 5,7 MiB entpackt)
Abrufen: gnome-terminal-lang-3.34.2-2.78.noarch.rpm .............................................[fertig]
Überprüfung auf Dateikonflikte läuft: ...........................................................[fertig]
(1/4) Installieren: libvte-2_91-0-0.58.3-1.32.x86_64 ............................................[fertig]
(2/4) Installieren: vte-lang-0.58.3-1.32.noarch .................................................[fertig]
(3/4) Installieren: gnome-terminal-3.34.2-2.78.x86_64 ...........................................[fertig]
(4/4) Installieren: gnome-terminal-lang-3.34.2-2.78.noarch ......................................[fertig]
Jetzt lösche ich es wieder:
zypper rm gnome-terminal
Installierte Pakete werden gelesen...
Paketabhängigkeiten werden aufgelöst...
Die folgenden 2 Pakete werden GELÖSCHT:
gnome-terminal gnome-terminal-lang
2 zu entfernende Pakete.
Nach dem Vorgang werden 8,8 MiB freigegeben.
Fortfahren? [j/n/v/...? zeigt alle Optionen] (j):
(1/2) gnome-terminal-lang-3.34.2-2.78.noarch wird entfernt .....................................[fertig]
(2/2) gnome-terminal-3.34.2-2.78.x86_64 wird entfernt ..........................................[fertig]
Und zurück bleiben mindestens 2 rpms als Leiche:
(1/4) Installieren: libvte-2_91-0-0.58.3-1.32.x86_64 ............................................[fertig]
(2/4) Installieren: vte-lang-0.58.3-1.32.noarch .................................................[fertig]
Oder ich lösche gleich mit --clean-deps:
zypper rm --clean-deps gnome-terminal
Installierte Pakete werden gelesen...
Paketabhängigkeiten werden aufgelöst...
Die folgenden 4 Pakete werden GELÖSCHT:
gnome-terminal gnome-terminal-lang libvte-2_91-0 vte-lang
4 zu entfernende Pakete.
Nach dem Vorgang werden 9,4 MiB freigegeben.
Fortfahren? [j/n/v/...? zeigt alle Optionen] (j):
(1/4) gnome-terminal-lang-3.34.2-2.78.noarch wird entfernt .....................................[fertig]
(2/4) vte-lang-0.58.3-1.32.noarch wird entfernt ................................................[fertig]
(3/4) gnome-terminal-3.34.2-2.78.x86_64 wird entfernt ..........................................[fertig]
(4/4) libvte-2_91-0-0.58.3-1.32.x86_64 wird entfernt ...........................................[fertig]
Es werden Programme ausgeführt, die immer noch die durch kürzliche Upgrades gelöschten oder aktualisierten Dateien oder Bibliotheken verwenden. Starten Sie die Programme neu, um die Aktualisierungen zu nutzen. Mit 'zypper ps -s' erhalten Sie eine Liste dieser Programme.
Meintest du das?
Und wenn ich die Abhängigkeit lösche, wird auch alles gelöscht:
zypper rm libvte-2_91-0
Installierte Pakete werden gelesen...
Paketabhängigkeiten werden aufgelöst...
Die folgenden 4 Pakete werden GELÖSCHT:
gnome-terminal gnome-terminal-lang libvte-2_91-0 vte-lang
4 zu entfernende Pakete.
Nach dem Vorgang werden 9,4 MiB freigegeben.
Fortfahren? [j/n/v/...? zeigt alle Optionen] (j):
(1/4) gnome-terminal-lang-3.34.2-2.78.noarch wird entfernt .....................................[fertig]
(2/4) vte-lang-0.58.3-1.32.noarch wird entfernt ................................................[fertig]
(3/4) gnome-terminal-3.34.2-2.78.x86_64 wird entfernt ..........................................[fertig]
(4/4) libvte-2_91-0-0.58.3-1.32.x86_64 wird entfernt ...........................................[fertig]
Siehe:
rpm -q --requires gnome-terminal
filesystem
libX11.so.6()(64bit)
libatk-1.0.so.0()(64bit)
libc.so.6()(64bit)
libc.so.6(GLIBC_2.2.5)(64bit)
libc.so.6(GLIBC_2.3.2)(64bit)
libc.so.6(GLIBC_2.4)(64bit)
libc.so.6(GLIBC_2.9)(64bit)
libdconf.so.1()(64bit)
libgdk-3.so.0()(64bit)
libgio-2.0.so.0()(64bit)
libglib-2.0.so.0()(64bit)
libgobject-2.0.so.0()(64bit)
libgtk-3.so.0()(64bit)
libpango-1.0.so.0()(64bit)
libpthread.so.0()(64bit)
libpthread.so.0(GLIBC_2.2.5)(64bit)
libuuid.so.1()(64bit)
libuuid.so.1(UUID_1.0)(64bit)
libvte-2.91.so.0()(64bit)
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(PayloadIsXz) <= 5.2-1
Ich verstehe nichts, weder den Kommentar oben noch diese Seite: Ubuntu Manpage: apt-mark - zeigt, setzt und hebt verschiedene Einstellungen für ein Paket auf. Das Zeug habe ich nie gebraucht. Zypper macht das automatisch. Vor einiger Zeit habe ich vlc installiert. Beim Entfernen von vlc macht zypper das:
**erlangen:~ #** **zypper rm --clean-deps vlc**
Reading installed packages...
Resolving package dependencies...
The following 35 packages are going to be REMOVED:
gimp-plugin-aa libBasicUsageEnvironment1 libSPIRV-Tools-suse23 libUsageEnvironment3 libaa1 libavc1394-0 libcddb2 libchromaprint1 libdca0 libdvbpsi10 libebml5 libfaad2 libglslang11 libgme0 libgroupsock30 libidn12 libixml11 liblirc_client0 libliveMedia102 libmatroska7 libplacebo157 libprojectM3 libschroedinger-1_0-0 libshaderc_shared1 libshout3 libupnp17 libvlc5 libvlccore9 vlc vlc-codec-gstreamer vlc-codecs vlc-lang vlc-noX vlc-qt vlc-vdpau
35 packages to remove.
After the operation, 71.5 MiB will be freed.
**Continue? [y/n/v/...? shows all options] (y): **n
**erlangen:~ #**
Hi zusammen,
nochmal Danke fürs dranbleiben
nur um das mal abzustecken, ich habe über 10 Jahre professionelle Erfahrung mit Linux-Systemen, nur eben nicht mit Suse. Das Konzept von Abhängigkeiten ist mir daher durchaus gut bekannt. Es kommt jetzt wegen SAP ein erstes Suse-Projekt, deswegen möchte ich mich mit dem System vertraut machen, und der Kern einer jeder neuen Distro ist für mich eben der Paketmanager.
Ich habe kein konkretes Problem dass es zu lösen gilt, mir geht es da ums Konzept.
Zypper muss ja zwei Zustände von installierten Paketen kennen und sie korrekt entfernen zu können: manuell installiert / als Abhängigkeit installiert. Ich möchte diesen Zustand manipulieren.
Beispiel: Paket A installiert B als Abhängigkeit. Ich möchte jetzt A entfernen, aber B behalten. Wie mache ich dass, ohne B zu deinstallieren und wieder zu installieren? Die Deinstallation birgt immer die Gefahr dass Daten verloren gehen, wenn es sich beispielsweise um eine Datenbank handelt.
Da ich die Paketlandschaft in Suse nicht kenne, kann ich leider keine Konkreten Beispiele nennen.
Mir ist jetzt kein solcher Fall erinnerlich. Falls eine Deinstallation unbedingt vermieden werden soll würde ich folgendes probieren:
zypper addlock B; zypper remove --clean-deps A; zypper removelock B
Apropos: Einer effektiven Wartung sehr förderlich ist die absichtliche Deinstallation und Reinstallation von Paketen.
Zypper kennt nur:
installiert ----- nicht installiert
Abhängigkeiten werden beim Bau des rpms definiert.
Benutze einfach kein --clean-deps siehe meine Beispiele oben, zypper rm löscht nur das Paket A, zypper rm --clean-deps löscht Paket A und B wenn B als Abhängigkeit bei der Installation von A mitinstalliert wurde.
Wenn Paket B noch als Abhängigkeit von installiertem Paket C ist, wird Paket B auch bei --clean-deps nicht deinstalliert.
Das stimmt nicht, zypper kennt als Stand “i” als abhängig installiert, und “i+” als manuell installiert. Sonst würde auch das Entfernen ungenutzter Abhängigkeiten auch nicht funktionieren.
Die Funktion der “Locks” werde ich mir mal anschauen, vielleicht ist es das was ich suche…
Das ist auch mein Verständnis.
Allerdings kann ich nicht sagen, wie es sich verhält wenn ein “pattern” (Schema) beteiligt ist.
Was die “Locks” anbelangt, so ist zu beachten, das Pakete, die mit einem “Lock” versehen sind, nicht installiert, nicht aktualisiert (!) und nicht gelöscht werden.
Viele Grüße
susejunky
Hi zusammen,
nochmal Danke für eure Geduld!
Um das ganze abzuschließen, wie so oft wusste das Arch-Wiki Bescheid
https://wiki.archlinux.org/title/Pacman/Rosetta
Zum Thema nachträglich als manuell markieren gibt es einen Workaround:
zypper install --force
(workaround which needs to reinstall the package)
Nachträglich als Abhängigkeit markieren ist seit 2020 ein Feature Request, der offenbar bis zum EOL ausgesessen und nicht umgesetzt werden wird, da das Feature für unnötig gehalten wird (steile These, alle anderen Paketmanager machen das auch nicht zum Spaß…) vgl. https://bugzilla.opensuse.org/show_bug.cgi?id=1175678
Das, zusammen mit dem dort verlinkten Bug https://bugzilla.opensuse.org/show_bug.cgi?id=1002507 der moniert dass die rekursive Entfernung unnötiger Abhängigkeiten nicht wirklich sauber funktioniert (2016 als Bug gemeldet, Status “Wont fix” weil sich keiner drum gekümmert hat, keine Ahnung wie der Stand aktuell ist), zeigt irgendwie dass Abhängigkeitsmanagement bei openSUSE wohl keine Prorität genießt, und die Community auch dahingehend keinen Handlungsbedarf sieht (Slackware lässt grüßen). Ich werde mein Testsystem noch etwas weiter betreiben, für den produktiven Einsatz wirkt openSUSE aber erstmal nicht konkurrenzfähig…
Ich nutze openSUSE bzw. seine Vorläufer seit der Version 7.1. Vor ca. 2 Jahren habe ich alle meine Systeme auf openSUSE Tumbleweed umgestellt; d.h. ich nutze seit dem ausschließlich zypper für das Paket-Management und ich muss sagen, die von Dir beschriebene Funktionalität habe ich noch nie vermisst. Aber jeder hat eben nun mal seine eigene Arbeitsweise …
Das kann ich so nicht bestätigen. Es kommt zwar nicht täglich vor, dass ich Pakete entferne, aber hin und wieder installiere ich schon einmal ein Paket, um es mir anzusehen und deinstalliere es kurz darauf wieder. Dabei steht das zypper in in der Konsole oft nur wenige Zeilen über dem zypper rm -u. Somit ist es relativ einfach zu vergleichen, ob alle installierten Pakete auch wieder deinstalliert werden. Mir ist es dabei noch nie vorgekommen, dass Pakete nicht wieder deinstalliert wurden.
Sollte ich da wirklich einfach nur Glück gehabt haben?
Wenn die von Dir vermisste zypper-Funktionalität tatsächlich der entscheidende Erfolgsfaktor für Deinen “produktiven Einsatz” ist, dann ist openSUSE wahrscheinlich wirklich nicht das geeignete System für Dich. Andererseits ist openUSE ein Community-Projekt und es steht Dir jederzeit frei diese für Dich so wichtige Funktionalität selbst einzubringen,
Viele Grüße
susejunky
Von Bug 1175678:
Especially a counterpart to this command is missing: apt-mark auto PACKAGE # remove manually installed property
Zypper führt die Liste /var/lib/zypp/AutoInstalled. Manuell installierte Pakete fehlen darin. Mit einem Editor kann der Paketname eingefügt werden. Zypper listet sie dann als “Installed: Yes (automatically)”.
Von Bug 1175678:
Also it would be very helpful if “zypper packages --unneeded” would work recursive. The command “zypper remove --clean-deps PACKAGE” already seems to work recursive. And Debian’s “apt autoremove” also does.
“zypper packages --unneeded” listet tatsächlich nur die unnötigen Pakete.
erlangen:~ # zypper packages --unneeded
Loading repository data...
Reading installed packages...
S | Repository | Name | Version | Arch
--+-------------------------+----------------------+------------+-------
i | openSUSE-Tumbleweed-Oss | dwarves | 1.22-2.1 | x86_64
i | openSUSE-Tumbleweed-Oss | kernel-macros | 5.15.8-1.1 | noarch
i | openSUSE-Tumbleweed-Oss | libelf-devel | 0.186-1.1 | x86_64
i | openSUSE-Tumbleweed-Oss | libgit2-1_3 | 1.3.0-1.1 | x86_64
i | openSUSE-Tumbleweed-Oss | libopenssl-1_1-devel | 1.1.1l-4.1 | x86_64
i | openSUSE-Tumbleweed-Oss | libopenssl-devel | 1.1.1l-1.2 | noarch
erlangen:~ #
Die Funktion von “apt autoremove” kann durch folgendes Kommandos erreicht werden:
erlangen:~ # **zypper packages --unneeded | grep ^i | cut -d '|' -f3 | xargs zypper remove --clean-deps**
Reading installed packages...
Resolving package dependencies...
The following 8 packages are going to be REMOVED:
dwarves kernel-macros libbpf0 libdwarves1 libelf-devel libgit2-1_3 libopenssl-1_1-devel libopenssl-devel
8 packages to remove.
After the operation, 5.5 MiB will be freed.
Continue? [y/n/v/...? shows all options] (y):
(1/8) Removing dwarves-1.22-2.1.x86_64 ....
(2/8) Removing kernel-macros-5.15.8-1.1.noarch ....
(3/8) Removing libelf-devel-0.186-1.1.x86_64 ....
(4/8) Removing libgit2-1_3-1.3.0-1.1.x86_64 ....
(5/8) Removing libopenssl-devel-1.1.1l-1.2.noarch ....
(6/8) Removing libdwarves1-1.22-2.1.x86_64 ....
(7/8) Removing libopenssl-1_1-devel-1.1.1l-4.1.x86_64 ....
(8/8) Removing libbpf0-0.5.0-1.1.x86_64 ....
erlangen:~ #
Hi Sauerland,
ich widerspreche Dir nur sehr ungern, aber zypper zeigt die automatisch installierten Pakete schon separat an. man zypper sagt:
**Query Commands**
**search **(**se**) [options] [querystring|capability]...
Search for packages matching any of the given search strings. *** **and **? **wildcard characters can be used within search strings. If the search string is enclosed in **/ **(e.g. **/^k.*e$/**) it’s interpreted as
a regularexpression. See the **install **command for details about how to specify a capability.
Results of the search are printed in a table with columns **S**tatus, **Name**, **Summary **and **Type **of package.
In the detailed view (**se -s**) all available instances of matching packages are shown; each version in each repository on a separate line, with columns **S**tatus, **Name**, **Type**, **Version**, **Arch**itecture and
**Repository**. For installed packages **Repository **shows either a repository that provides exactly the installed version of the package, or, if the exact version is not provided by any known repo, **(System**
**Packages) **(or **@System**). Those installed packages not provided by any repo are often denoted as being unwanted, orphaned or dropped.
The **S**tatus column can contain the following values:
**i+**
installed by user request
**i**
installed automatically (by the resolver, see section **Automatically installed packages**)
**Automatically installed packages**
Packages added by the dependency solver in order to resolve a user’s request are remembered as having been automaticallyinstalled. They may later be removed, if no more user installed packages depend on
them (e.g. by **zypper remove --clean-deps**).
Ich würde ja fast sagen, robinrosenberger braucht nur die -U Option zum Entfernen um sicherzugehen:
zypper rm --no-clean-deps paket
Ich weiß es nicht genau, aber ich glaube das “–clean-deps” könnte eine Default-Einstellung sein.
Ups, da habe ich eine ganze Seite Antworten übersehen…
:shame:
Heureka, das ist es, vielen Dank 
ich gehe davon aus, dass man da sowohl reinschreiben als auch entfernen kann, das bildet die gesuchte Funktion komplett ab. Das müsste dringend in die Manpage, die Frage wird wirklich viel im Netz gestellt.
Mit der o.g. Info wäre das in der Tat leicht machbar, aber mit der o.g. Info ist das wohl auch tatsächlich überflüssig.
Bei der Eignung für Produktivsysteme ging es nicht so konkret um die einzelne Funktion, sondern darum welcher Stellenwert dem Anhängigkeitsmanagement zugeordnet wird. Dieses macht nach meiner Erfahrung einen großen Teil der langfristigen Stabilität eines Systems aus, insbesondere bei Major-Updates in Microservice-Maschinen kann das echt Kopfschmerzen machen.
Aus den Bug-Reports, sowie der typischen Antwort die ich mehrfach, auch auf Reddit und Co., gefunden habe die sinngemäß “Das braucht man nicht” lautet, müsste man, wenn es wirklich nicht gehen würde, schließen dass das Thema sehr stiefmütterlich behandelt wird, was einer Distro die Enterprise-Level haben will überhaupt nicht gut stünde.
Danke an alle, die sich mit mir Gedanken gemacht haben! Ich würde mich echt freuen eine stabile, releasebasierte Distro zu finden die auf btrfs-root funktioniert (RHEL/CentOS 8 kann kein btrfs mehr, bei Debian/Ubuntu ist dpkg unterirdisch langsam…)
Gern geschehen. Vielen Dank für die Rückmeldung. Hier gibt es einen Vorschlag: Support for exposing /var/lib/zypp/AutoInstalled · Issue #89 · openSUSE/zypper · GitHub