Seiten: [1] 2
|
|
|
|
Autor
|
Thema: Wiki - ALPM Datenbankpflege Diskussionsthread (Gelesen 3425 mal)
|
|
Sebastian
YaBB God
Offline
Einträge: 521
|
|
Wiki - ALPM Datenbankpflege Diskussionsthread
« am: 23. September 2022, 07:52:43 »
|
|
Dies ist der Diskussionsthread der ALPM Datenbankpflege Wikiseite
Fragen, Anregungen etc. Alles hier rein
LG Sebastian
|
« Letzte Änderung: 24. Mai 2024, 16:02:23 von Sebastian » |
Gespeichert
|
Richtig um Hilfe bitten
|
|
|
Andreas
Administrator
Offline
Einträge: 1345
Linux von Innen
|
|
Re:Pacman Datenbank Pflege
« Antwort #1 am: 23. September 2022, 11:23:27 »
|
|
Danke für die gute Erläuterung, Sebastian! Für jemanden der mit einem neuen System anfängt (wenn die Liste der Pakete die "orphaned" sind noch kurz ist) mag das in der Tat hilfreich sein. Ist das System aber erstmal gewachsen: dann überfordert diese Art der Pflege selbst "Profis"... Ich werde damit definitiv nicht anfangen - ich würde Tage für die Pflege brauchen und garantiert dabei auch Fehler machen. Fehler, die nicht unbedingt sofort auffallen, sondern erst viel später. Hier meine Ausgabe:[andreas@wst-andreas ~]$ pacman -Qtdq addinclude ant arandr archlinux-keyring arcus-debug asciidoc asciidoctor aspell-en atril automoc4 awesome-terminal-fonts baobab brasero brisk-menu brltty bullet byzanz caja-gksu caja-open-terminal celt celt0.5.1 ceph-libs cgal check chrpath cinnamon clementine cm256cc coffeescript conky-manager cpio cppunit cunit cython2 dconf-editor deepin-boot-maker deepin-calendar deepin-clone deepin-grub2-themes deepin-help deepin-image-viewer deepin-music deepin-network-utils deepin-picker deepin-qml-widgets deepin-screen-recorder deepin-system-monitor deepin-voice-note deepin-wallpapers-extra dmd doxygen dssi eog eom erlang-sdl expect fcgi fuse-overlayfs gdl gedit gegl02 gendesk gengetopt ghostpcl ghostxps giblib gmetadom gmrun gnome-calculator gnome-calendar gnome-common gnome-contacts gnome-documents gnome-font-viewer gnome-icon-theme gnome-logs gnome-maps gnome-mplayer gnome-music gnome-perl gnome-photos gnome-screenshot gnome-shell-extension-dash-to-dock gnome-shell-extension-status-menu-buttons gnome-software gnome-system-monitor gnome-tweaks gnome-weather gnuradio-fcdproplus gnuradio-iio-git gperf gpicview gradle gsimplecal gstreamer-vaapi gtest gtk-sharp-3 gtk-theme-adapta gtk-theme-paper gtk-xfce-engine gtkmm-4.0 gtkspell gtkspell3 gulp help2man hunspell-el hunspell-en_gb hunspell-es_any hunspell-fr hunspell-he hunspell-hu hunspell-it hunspell-nl hunspell-pl hunspell-ro i3-wm icon-naming-utils idnkit iso-flag-png java-testng jbigkit js js38 js52 js60 js68 kalarmcal kde-servicemenus-rootactions kdepim-apps-libs kdesignerplugin kfaenza-icon-theme kipi-plugins kjsembed ksysguard kxmlrpcclient lazarus leveldb lhasa lib32-cracklib lib32-dconf lib32-gconf lib32-libcroco lib32-libgusb lib32-libidn lib32-libnm-glib lib32-libva1 lib32-lz4 lib32-pcre libappindicator-gtk2 libcmis libdbi-drivers libdmx libechonest libftdi-compat libgnomecups libgsystem libgweather libhandy0 libicns libkvkontakte liblastfm-qt4 libmagick6 libmirisdr-git libmp4v2 libnm-gtk libopenaptx libosmosdr-git libquicktime libquvi librabbitmq-c librdkafka libstdc++5 libtg_owt libunique libxxf86dga libxxf86misc light-locker-settings lightdm-webkit2-greeter limesuite linuxdoc-tools lockdev lua51 lxappearance-obconf-gtk3 lxinput-gtk3 lxqt-notificationd lxtask-gtk3 lzip mate-applets mate-backgrounds mate-calc mate-control-center mate-media mate-notification-daemon mate-polkit mate-power-manager mate-screensaver mate-system-monitor mate-terminal mate-themes mate-user-guide mate-utils mesa-demos mlt-python2-bindings moc mono-addins mousepad mozilla-common mozo mypaint-brushes nanomsg nemo-fileroller nemo-preview nemo-share nethogs nitrogen notify-osd numix-frost-themes numix-icon-theme-square obconf obkey obmenu ocaml-findlib ocaml-num openbox-menu opencolorio1 openjpeg opera pangox-compat parcellite parole pcmanfm-qt perl-extutils-depends perl-extutils-pkgconfig perl-gnome2-wnck perl-gtk2-imageview perl-test-deep perl-test-differences perl-test-exception perl-test-memory-cycle perl-test-mockobject perl-test-needs perl-test-pod plank-theme-numix pluma po4a polari pragha premake progsreiserfs properties-cpp pth python-asn1crypto python-beaker python-build python-cachecontrol python-cherrypy python-cmd2 python-contextlib2 python-dae python-defusedxml python-distutils-extra python-elasticsearch python-flask-restful python-google-api-python-client python-installer python-isodate python-jaraco.packaging python-jieba python-mock python-nose python-pecan python-pgi python-pkgconfig python-prettytable python-progress python-prometheus_client python-pyaml python-pydbus python-pyhamcrest python-pyjwt python-pylint python-pytest-black python-pytest-checkdocs python-pytest-cov python-pytest-enabler python-pytest-flake8 python-pytest-localserver python-pytest-mypy python-pythran python-resolvelib python-retrying python-rich python-rst.linker python-scikit-learn python-setuptools-scm python-sip-pyqt5 python-sphinx_rtd_theme python-sphinxcontrib-websupport python-tenacity python-termcolor python-tinycss python-types-python-dateutil python-whoosh python-xmlsec python-zipfile-deflate64 python2-apipkg python2-apsw python2-certifi python2-cheetah python2-css-parser python2-cssutils python2-dukpy python2-feedparser python2-flaky python2-genty python2-graphviz python2-html2text python2-iniconfig python2-keybinder2 python2-m2r python2-markupsafe python2-matplotlib python2-mechanize python2-mock python2-msgpack python2-mutagen python2-ndg-httpsclient python2-netifaces python2-nose python2-olefile python2-ordered-set python2-packaging python2-pam python2-pexpect python2-pretend python2-psutil python2-pychm python2-pycryptodomex python2-pyinotify python2-pyqtwebengine python2-pyside2 python2-pytest-cov python2-pytest-expect python2-pytest-freezegun python2-pytest-runner python2-pytest-timeout python2-pyxdg python2-regex python2-requests python2-setuptools-scm python2-sip python2-sip-pyqt4 python2-subprocess32 python2-suds python2-trollius python2-unrardll python2-wheel python2-xlib python2-yaml qimageblitz qt5-styleplugins qt5ct qt6-shadertools qtcurve-gtk2 qtcurve-kde qtcurve-qt4 qtwebkit-bin rabbitmq rapidjson ristretto rttr ruby-sass sassc shiboken2 sip sip4 swig swt systemd-manager tde-tqt3-docs tepl termite termite-terminfo time tint2 totem transmission-gtk transmission-qt treefrog-framework udiskie unbound unicode-character-database vala valgrind volumeicon waldorf-ui-theme xf86-video-vesa xfburn xfce4-appfinder xfce4-battery-plugin xfce4-datetime-plugin xfce4-dev-tools xfce4-power-manager xfce4-pulseaudio-plugin xfce4-screenshooter xfce4-session xfce4-settings xfce4-taskmanager xfdesktop xfwm4-themes xmlstarlet xmlto xorg-font-utils xorg-fonts-100dpi xorg-fonts-misc xorg-server-xvfb xorg-sessreg xorg-smproxy xorg-util-macros xorg-x11perf xorg-xbacklight xorg-xcmsdb xorg-xcursorgen xorg-xdriinfo xorg-xev xorg-xgamma xorg-xinput xorg-xkbevd xorg-xkbutils xorg-xkill xorg-xlsatoms xorg-xlsclients xorg-xpr xorg-xrefresh xorg-xvinfo xorg-xwd xorg-xwud yarn yasm zint zita-alsa-pcmi zita-resampler zuki-themes |
|
Sind diese Pakete wirklich "orphaned und können gelöscht werden?"- archlinux-keyring
- cinnamon (Desktop-Umgebung)
- gnome-contacts (als eine von vielen Anwendungen die man unter gnome unbedingt braucht)
- mate-control-center (als eine von vielen Anwendungen die man unter gnome unbedingt braucht)
- xfce4-taskmanager (als eine von vielen Anwendungen die man unter gnome unbedingt braucht)
- die vielen xorg-* - Pakete (habe ich schon Bauchschmerzen mit)
|
« Letzte Änderung: 23. September 2022, 11:30:53 von Andreas » |
Gespeichert
|
Wissen ist das einzige Gut, das mehr wird, wenn man es teilt - wenn es Menschen gibt, die es teilen, und es Menschen gibt, die bereit sind, dieses Geschenk auch mit eigenem Einsatz anzunehmen.
Freiheit zu erkämpfen reicht nicht. Man muss sie auch verteidigen.
Ohne IT-Kompetenz ist man heutzutage ein willkommenes Opfer und Spielball anderer, egal, welches System oder Gerät man nutzt. Nur Wissen schützt vor Schaden!
|
|
|
Sebastian
YaBB God
Offline
Einträge: 521
|
|
Re:Pacman Datenbank Pflege
« Antwort #2 am: 23. September 2022, 15:26:49 »
|
|
Klar Andreas, sind da bei dir auch Pakete mit dabei, die nicht weg dürfen. Ein Paar hast du ja schon aufgezählt. Es ist bei dir aber sowieso eigenartig, warum diese teileweise wichtigen Pakete als Installationsgrund als Abhängigkeit in der Datenbank drin stehen. Und nicht als ausdrücklich installiert markiert sind.
Zudem dürfte archlinux-keyring in der Auflistung nicht auftauchen. Da dies eigentlich eine Abhängigkeit von dem Paket base ist. Und damit mit dem Filter pacman -Qt überhaupt nicht getroffen werden dürfte. Und das base Paket müsstest du doch haben, oder? Da dies in deiner Ausgabe auch nicht auftaucht.
Demzufolge hast du base nicht (was ich nicht glaube) oder du hast eine andere Version von base die den archlinux-keyring nicht als Abhängigkeit hat. Vielleicht verhält es sich bei anderen Paketen bei dir so ähnlich.
Könntest du die Ausgabe von diesem Befehl mal posten. Mich interessiert das jetzt sehr stark, warum das Paket bei dir in der Ausgabe auftaucht.
pacman -Qi base archlinux-keyring
|
|
Ansonsten könntest du den Installationsgrund für die Pakete, die es in Gruppen gibt, wie die Desktopumgebungen oder xorg etc. mit diesem Befehl als ausdrücklich installiert setzten.
Hier anhand des Beispiels von der XFCE4 Desktopumgebung + die Goodies
pacman -Qgq xfce4 xfce4-goodies | sudo pacman -D --asexplicit -
|
|
Du kannst auch gerne den Befehl vor der Pipe erst einmal alleine ausführen, damit du siehst welche Pakete auf Ausdrücklich installiert gesetzt würden. Machst du das bei allen deiner Desktop Umgebungen, dann wird die Liste schon erheblich kleiner.
|
« Letzte Änderung: 23. September 2022, 15:28:32 von Sebastian » |
Gespeichert
|
Richtig um Hilfe bitten
|
|
|
Andreas
Administrator
Offline
Einträge: 1345
Linux von Innen
|
|
Re:Pacman Datenbank Pflege
« Antwort #3 am: 23. September 2022, 17:05:24 »
|
|
In der Tat habe ich das Paket "base" nicht installiert - in keiner meiner Installationen. Und alle drei völlig voneinander unabhängigen (Multidesktop, nur KDE und raspberry Pi) laufen einwandfrei... Ich habe aber das Paket "base-devel" - weil ich ja auch mit den AURs arbeiten will.
LG Andreas
|
« Letzte Änderung: 23. September 2022, 17:05:50 von Andreas » |
Gespeichert
|
Wissen ist das einzige Gut, das mehr wird, wenn man es teilt - wenn es Menschen gibt, die es teilen, und es Menschen gibt, die bereit sind, dieses Geschenk auch mit eigenem Einsatz anzunehmen.
Freiheit zu erkämpfen reicht nicht. Man muss sie auch verteidigen.
Ohne IT-Kompetenz ist man heutzutage ein willkommenes Opfer und Spielball anderer, egal, welches System oder Gerät man nutzt. Nur Wissen schützt vor Schaden!
|
|
|
Sebastian
YaBB God
Offline
Einträge: 521
|
|
Re:Pacman Datenbank Pflege
« Antwort #4 am: 23. September 2022, 18:26:19 »
|
|
Dann ist mit der Ausgabe von pacman -Qtdq alles in Ordnung, dann müsstest du bei dir denn Installationsgrund wirklich bei dem archlinux-keyring auf Ausdrücklich installiert setzten. Da bei dir der archlinux-keyring somit keine Abhängigkeitsquelle hat und damit ausdrücklich gewünscht/installiert sein sollte. Der Grund dafür ist der, dass base-devel kein richtiges Paket ist, sondern eine Paketgruppe, indem die Pakete als Liste nacheinander installiert werden, und somit nicht unbedingt eine Abhängigkeitsquelle besitzen müssen. Demnach solltest du die Pakete in der base-devel Gruppe die du irgendwann ausdrücklich installiert hast, den Installationsgrund für die Pakete in dieser Gruppe auch auf ausdrücklich installiert ändern.
pacman -Qgq base-devel | sudo pacman -D --asexplicit -
|
|
In dieser Gruppe ist auch der archlinux-keyring mit drin enthalten. Damit wird die Ausgabe von pacman -Qtdq auch wieder ein ganzes Stück kürzer.
Früher war base auch eine Gruppe, diese wurde aber zu einem Metapaket umgewandelt, um Abhängigkeiten wie z.B. zu dem archlinux-keyring herzustellen. Dies wurde bei der base-devl Gruppe nicht gemacht.
https://archlinux.org/news/base-group-replaced-by-mandatory-base-package-manual-intervention-required/
Anscheint, sind bei dir die Installationsgründe von Pakten, die von Gruppen kommen viele falsch gesetzt. (base-devel, xorg, Desktopumgebungen etc). Damit scheinst du echt Glück zu haben, denn dadurch kannst du dir sicher sein, dass all diese Pakete in diesen Gruppen den Grund ausdrücklich installiert haben sollten. Da du früher schließlich diese Pakete haben wolltest.
EDIT:
Was du natürlich auch machen kannst, nachdem du die Installationsgründe von den Pakten in der Gruppe base-devel korrigiert hast, das Metapaket base nachzuinstallieren. Dann würden folgende Pakete installiert werden, falls noch nicht vorhanden und eine Abhängigkeitsquelle bekommen:
filesystem gcc-libs glibc bash coreutils file findutils gawk grep procps-ng sed tar gettext pciutils psmisc shadow util-linux bzip2 gzip xz licenses pacman archlinux-keyring systemd systemd-sysvcompat iputils iproute2
|
|
Dann wenn man möchte, könnte man den Installationsgrund von den Pakten die durch das Metapaket base abgedeckt sind, wieder zurück als Abhängigkeit zurückstellen. Da diese dann ja auch schließlich von base abhängen, und laut Definition (pacman -Qtd)
Kein anderes Paket benötigt es mehr + (Installationsgrund = als Abhängigkeit installiert)
Keine Orpahns mehr sind.
sudo pacman -D --asdeps filesystem gcc-libs glibc bash coreutils file findutils gawk grep procps-ng sed tar gettext pciutils psmisc shadow util-linux bzip2 gzip xz licenses pacman archlinux-keyring systemd systemd-sysvcompat iputils iproute2
|
|
Diese Pakte hängen dann alle als Abhängigkeit an base dran.
Denn Installationsgrund kann man natürlich trotzdem weiterhin auch auf ausdrücklich installiert stehen lassen. Das schadet auch nicht da man ja schließlich diese Pakete sowieso behalten will. Und man base höchst wahrscheinlich samt seinen Abhängigkeiten nicht mehr Deinstallieren möchte.
|
« Letzte Änderung: 24. September 2022, 06:30:29 von Sebastian » |
Gespeichert
|
Richtig um Hilfe bitten
|
|
|
Andreas
Administrator
Offline
Einträge: 1345
Linux von Innen
|
|
Re:Pacman Datenbank Pflege
« Antwort #5 am: 24. September 2022, 06:50:44 »
|
|
Alles richtig Sebastian. Ich habe mal geschaut was nachgezogen wird wenn ich "base" nachinstalliere: gar nichts. War also alles schon da. Und genau diese Sachen wie "...war früher mal...", "...ist inzwischen..." wird die Datenbank, wenn dein System schon älter ist, immer komplexer und Du kannst mit "Löschen" alles kaputt machen. Dieser "Datenbankpflegemechanismus" ist kein selbstlaufender Automat - man muss ihn selbst steuern und dazu braucht man extrem viel Wissen. Wissen dass (ich hoffe ich beleidige jetzt niemand aus unserer Gruppe) wohl nur wir beide haben - und viele weder erreichen wollen noch erreichen werden. In sofern denke ich dass ein paar hundert Megabyte (lass es 5GB sein) an Pakeeten, die kein Mensch mehr braucht das Glück des Linux-Users nicht wirklich beeinträchtigen. Welche Datei zu welchem Paket gehört wird trotzdem überwacht und bei Konflikten wirst Du informiert. Wenn Du dann handelst - machst Du alles richtig. Ich lasse auch die vielen Python2-Pakete noch auf meinem System. Ich habe einige Technik-Programme die auf Python2 basieren, es gibt sie noch nicht auf Python3 (vielleicht gibt es sie niemals für Python3) - und die brauchen auch nicht upgedatet zu werden weil sie genau das tun was sie sollen - bugfrei. Die schleppe ich dann eben mit. Etliche gibt es auch nicht mehr in den Repos / AURs. Ich habe sie noch und kann mit fakepkg ein installierbares Paket erzeugen...
Ich bin kein "Hubschrauber-User" - ich muss mein Linux-System nicht "überhüten"
EDIT: Bei meinem Raspi ist archlinux-keyring in Abhängigkeit von base-devel installiert - nicht in Abhängigkeit von "base".
LG Andreas
|
« Letzte Änderung: 24. September 2022, 07:02:50 von Andreas » |
Gespeichert
|
Wissen ist das einzige Gut, das mehr wird, wenn man es teilt - wenn es Menschen gibt, die es teilen, und es Menschen gibt, die bereit sind, dieses Geschenk auch mit eigenem Einsatz anzunehmen.
Freiheit zu erkämpfen reicht nicht. Man muss sie auch verteidigen.
Ohne IT-Kompetenz ist man heutzutage ein willkommenes Opfer und Spielball anderer, egal, welches System oder Gerät man nutzt. Nur Wissen schützt vor Schaden!
|
|
|
Sebastian
YaBB God
Offline
Einträge: 521
|
|
Re:Pacman Datenbank Pflege
« Antwort #6 am: 24. September 2022, 08:32:05 »
|
|
Dieser "Datenbankpflegemechanismus" ist kein selbstlaufender Automat - man muss ihn selbst steuern und dazu braucht man extrem viel Wissen.
|
|
Da pflege ich dir absolut bei, da ist kein Automatismus dahinter, sondern erfordert manuelle Pflege. Nur ob man dafür extrem viel wissen brauch, das kann ich ga nicht genau abschätzen. Eigentlich muss man nur die Beziehungen zwischen Pakten und ihren Abhängigkeiten und wofür die Installationsgründe gut sind verstanden haben.
Um das zu lernen, hilft wirklich das Programm pactree, mit dem man sich einen Abhängigkeit-Zweig von einem Paket sich Bildlich darstellen, lassen kann. Einzig etwas irritierend ist die Ausgabe von pactree -r wenn man die Zweig-Richtung umdreht, um zu schauen, welche Pakte das angebende Paket brauchen. Bildlich müsste der Zweig von unten nach oben verlaufen. Und nicht weiterhin von oben nach unten angezeigt werden.
Was die Pakete einer arm basierten Architektur anbelangt, da kenne ich mich nicht mit aus. Da ich https://archlinuxarm.org/ für meinen Pi noch nicht nutze. Und ich da auch keine Gruppen Übersicht auf der Seite finde. Vielleicht werden die Pakete für arm etwas anders gebaut was die Abhängigkeiten anbelangt, wobei auch dort das base Paket den archlinux-keyring als Abhängigkeit hat. Ist ja auch dasselbe Paket von Archlinux
Ich hoffe auch nicht das sich dadurch jemand beleidigt fühlt, (zumindest sollte sich keiner beleidigt fühlen). Wenn jemand einen sagt, das man dort noch eine Wissenslücke hat. Es ist ja auch nichts Schlimmes dabei nicht alles zu wissen (kann man ja auch nicht) dies kann ja auch schließlich geändert werden, wenn man es denn auch möchte. Wenn nicht, ist das auch nicht schlimm, man bleibt dann halt ein Stück weit von anderen abhängig.
Wenn du mir sagen würdest das ich vielleicht etwas noch nicht ganz verstanden habe oder ich hier und da noch was Nachschlagen kann. Sehe ich das als gelegenheit noch etwas dazuzulernen. Man lernt ja schlisslich nie aus
Zudem
Wissen ist das einzige Gut, das mehr wird, wenn man es teilt - wenn es Menschen gibt, die es weitergeben, und es Menschen gibt, die bereit sind, dieses Geschenk auch unter eigenem Einsatz anzunehmen.
|
|
Und wenn das deine Aufassung eines "Hubschrauber-Users" ist der dafür, sorgt das, die Beziehungen zwischen den Pakten bzw. denn Installationsgründen stimmig ist so das die Ausgabe von pacman -Qtd leer bleibt. Dann bekenne ich mich gerne dazu, ist ja nichts Schlimmes daran das alles in Schuss zu halten, besonders wenn man grade neu angefangen hat und die Datenbank noch in einem sauberen Zustand ist. Und nicht gleich mit ein paar manuellen Eingriffen hier und da überfordert wird. Vielleicht sieht das in ein paar Jahren bei mir ja auch anders aus und ich werde auch pflege müde. Aber bis jetzt sehe ich das noch nicht. Da mir Archlinux zurzeit echt Spaß macht und ich wirklich schnell vieles neues dazu lernen kann.
Also alles gut
LG
Sebastian
|
« Letzte Änderung: 24. September 2022, 08:39:04 von Sebastian » |
Gespeichert
|
Richtig um Hilfe bitten
|
|
|
Andreas
Administrator
Offline
Einträge: 1345
Linux von Innen
|
|
Re:Pacman Datenbank Pflege
« Antwort #7 am: 24. September 2022, 09:22:25 »
|
|
Mein kurzer Kommentar: alles gut!!!
Ich finde die Tutorials die Du da verfasst absolut klasse. Sie sind kurz und verständlich verfasst und berühren wichtige Themen. Ich kommentiere an einigen Stellen nur aus einem einzigen Grund:
Ich möchte die, die zwar die Eingabe der Befehle verstehen und "ganz grob" die Zusammenhänge, vor einer Katastrophe bewahren. Wir haben noch kein Feedback von Manfred ob nach der Entfernung von über 200 angeblich "überflüssigen" Paketen weitere Probleme aufgetreten sind. Ich befürchte dass es so ist, und ich befürchte auch dass sich diese Probleme nicht alle einfach lösen lassen.
Gerade wenn man viele Pakete aus den AURs hat ist die Qualität der Paketdatenbank niedriger. Viele Pakete aus den AURs sind sntstanden weil jemand genau das eine Paket vermisst hat. Er war fit genug es aus den Quellen selbst zu bauen (github oder svn) und hat ein PKGBUILD dazu erstellt - und es über den Mechanismus der AURs anderen zur Verfügung gestellt. Er wollte oft nur das Paket selbst nutzen und hat von Anfang an keine Perfektion im Gedanken gehabt. Und da rutscht dann schon mal eine Abhängigkeit durch - in beide Richtungen. Selbst bei der eigenen Pflege der Datenbank können einem solche Abhängigkeiten durchrutschen. Weil man ein benötigtes Paket zufällig schon installiert hat und deswegen der Bau gelingt. So können auch auf einem System bei dem die Ausgabe von pacman -Qtd leer bleibt noch Paket-Abhängigkeits-Probleme schlummern: sie sind aber nicht sichtbar. Ich habe jahrelang ein Debian-basiertes Rolling-Release genutzt und betreut (Siduction). Dort ist der Paketverwaltungsmechanismus nicht so ausgefeilt wie bei Arch. Zumindest bin ich dort öfter in solche Abhängigkeitsfallen getappt (mindestens einmal im Monat) - oft verbunden mit Stunden des Suchens und weiteren Stunden der Beseitigung des Problems. Davor möchte ich die Nutzer meiner Installationen, die sehr viele AUR-Pakete beinhalten, schützen. Alles was mit "entfernen" zu tun hat sollte man wirklich, wirklich, wirklich, wirklich, wirklich, wirklich, wirklich, wirklich, ganz genau wissen!!!!!! Ein grobes Verständnis des Aufbaus der Paketdatenbank ohne sich bewusst zu sein wie genau die aufgebaut wird und in wie weit man sich auf die Richtigkeit verlassen kann kann einen zum Bestätigen mit "ja" verleiten...
Ich schreibe aus langer Erfahrung. Auch ich bin früher öfter in solche Fallen gelaufen und nur da rausgekommen weil ich regelmäßig Backups mache (schon seit Jahrzehnten). Die letzten solcher Fallen hatte ich bei der Systempflege von "Siduction". Ich würde sie jetzt wieder haben wenn ich meine Debian-basierten Distris "LMDE" weiter pflegen würde - das gebe ich aber auf. Weil es eine "unendliche Geschichte" ist. Seit ich Arch nutze habe ich solche Probleme noch niemals gehabt. Und da selbst mir eine unerkannte Abhängigkeit durchrutschen kann weswegen ich ein Paket das ich nicht mehr wiederbekomme lösche nur damit die Ausgabe von pacman -Qtd leer bleibt - ich dafür aber ein wichtiges aber selten benutztes altes Tool zerschossen habe: möchte ich die denen solche Erfahrungen noch nicht zu Teil geworden sind warnen...
LG Andreas
|
|
Gespeichert
|
Wissen ist das einzige Gut, das mehr wird, wenn man es teilt - wenn es Menschen gibt, die es teilen, und es Menschen gibt, die bereit sind, dieses Geschenk auch mit eigenem Einsatz anzunehmen.
Freiheit zu erkämpfen reicht nicht. Man muss sie auch verteidigen.
Ohne IT-Kompetenz ist man heutzutage ein willkommenes Opfer und Spielball anderer, egal, welches System oder Gerät man nutzt. Nur Wissen schützt vor Schaden!
|
|
|
Andreas
Administrator
Offline
Einträge: 1345
Linux von Innen
|
|
Re:Pacman Datenbank Pflege
« Antwort #8 am: 24. September 2022, 11:25:14 »
|
|
Was passiert mit Paketen die ich als "optionale Dependencies" bei der Installation eines "Hauptpaketes" gleich alle mitinstalliert habe? Das mache ich nämlich sehr oft, weil ich in der Vergangenheit oft gemerkt habe dass ich solche optionalen Dinge später oft brauche und es manchmal sehr mühselig (ab und zu sogar unmöglich) ist diese später nachzuinstallieren?
Wenn diese Pakete in der Datenbank das Attribut "installiert als Abhängigkeit" bekommen und logischerweise nicht als "explizit benötigt von" irgendwo erscheinen könnten diese dann doch in die Liste der zu löschenden Aspiranten wandern? So wie ich das bisher herausgefunden habe sind alle Pakete die ich in der "zu löschenden Liste" sehe als Installationsgrund "in Abhängigkeit installiert" - und tauchen teilweise bei anderen Paketen als "optionalöe Abhängigkeit" auf. Interessant wäre ob es mittels expac eine Möglichkeit gibt zu schauen ob irgendein Paket aller installierten Pakete die optionale Abhängigkeit "xyz" hat...
LG Andreas
|
« Letzte Änderung: 24. September 2022, 11:35:04 von Andreas » |
Gespeichert
|
Wissen ist das einzige Gut, das mehr wird, wenn man es teilt - wenn es Menschen gibt, die es teilen, und es Menschen gibt, die bereit sind, dieses Geschenk auch mit eigenem Einsatz anzunehmen.
Freiheit zu erkämpfen reicht nicht. Man muss sie auch verteidigen.
Ohne IT-Kompetenz ist man heutzutage ein willkommenes Opfer und Spielball anderer, egal, welches System oder Gerät man nutzt. Nur Wissen schützt vor Schaden!
|
|
|
Sebastian
YaBB God
Offline
Einträge: 521
|
|
Re:Pacman Datenbank Pflege
« Antwort #9 am: 24. September 2022, 18:28:47 »
|
|
Was passiert mit Paketen die ich als "optionale Dependencies" bei der Installation eines "Hauptpaketes" gleich alle mitinstalliert habe? Das mache ich nämlich sehr oft, weil ich in der Vergangenheit oft gemerkt habe dass ich solche optionalen Dinge später oft brauche und es manchmal sehr mühselig (ab und zu sogar unmöglich) ist diese später nachzuinstallieren?
|
|
Wie hast du denn die optionalen Pakete gleich mitinstalliert? Gibt es da einen Trick? Ich hatte bis dato den Fall noch nicht gehabt, dass ich viele optionale Pakete nachinstallieren musste. Falls der Fall mal eintreten sollte würde ich das so machen, nachdem ich das Hauptpaket (Am Beispiel pacgraph) installiert hätte:
expac -l "\n" "%o" pacgraph | sudo pacman -S --asdeps --needed -
|
|
Die optionalen Abhängigkeiten natürlich als --asdeps damit sie später wieder leicht mit deinstalliert werden können, und --needed damit vorhanden Pakete nicht noch mal installiert werden und ganz wichtig der Installationsgrund von bereits installierten Paketen nicht geändert wird. Nicht das ich aus Versehen ein ausdrücklich installiertes zur Abhängigkeit mache, als Installationsgrund.
Edit: Wenn ich merke das ich eine optionale Abhängigkeit an sich unabhängig von dem davor installierten Haupt Paket nutze, sprich also selbst haben möchte, ändere ich den Installationsgrund von diesem Paket auf ausdrücklich installiert. Damit ich bei einer Deinstallation des Hauptpakets (pacman -Runs) das nicht mit deinstalliert wird. Edit Ende
Wenn diese Pakete in der Datenbank das Attribut "installiert als Abhängigkeit" bekommen und logischerweise nicht als "explizit benötigt von" irgendwo erscheinen könnten diese dann doch in die Liste der zu löschenden Aspiranten wandern?
|
|
pacman -Qtdq nein pacman -Qttdq ja yay -Yc nur, wenn die ganze Kette nach oben alle Pakete den Installationsgrund als Abhängigkeit installiert haben. Ist ein Paket dazwischen mit ausdrücklich installiert, dann werden die darunter auch nicht getroffen (grade ausprobiert).
man pacman
-t, --unrequired Restrict or filter output to print only packages neither required nor optionally required by any currently installed package. Specify this option twice to include packages which are optionally, but not directly, required by another package.
|
|
Edit: yay -Yc ist also Quasi eine Kombination aus pacman -Qtdq und -Qttdq
Beispiel:
pacman -Qtd
pacgraph (--asexplicit) # Wird nicht getroffen, (Filter -d) ├─python (--asexplicit) # Wird nicht getroffen, (Filter -d) ├─inkscape (optional, --asdeps) # Wird nicht getroffen, (Filter -t) ├─imagemagick (optional, --asdeps) # Wird nicht getroffen, (Filter -t) └─tk (optional --asdeps) # Wird nicht getroffen, (Filter -t)
pacgraph (--asdep) # Wird getroffen, ├─python (--asexplicit) # Wird nicht getroffen, (Filter -d) ├─inkscape (optional, --asdeps) # Wird nicht getroffen, (Filter -t) ├─imagemagick (optional, --asdeps) # Wird nicht getroffen, (Filter -t) wird noch optional von pacgraph und anderen Paketen gebraucht └─tk (optional --asdeps) # Wird nicht getroffen, (Filter -t) wird noch optional von pacgraph,python und git gebraucht
# Würde man pacgraph jetzt entfernen
pacman -R pacgraph
# sieht es bei pacman -Qtd nun so aus:
pacgraph (Entfernt) ├─python (--asexplicit) # Wird nicht getroffen, (Filter -d) ├─inkscape (optional, --asdeps) # Wird getroffen, (Filter -t) ├─imagemagick (optional, --asdeps) # Wird nicht getroffen, (Filter -t) Wird von anderen Paketen noch gebraucht └─tk (optional --asdeps) # Wird nicht getroffen, (Filter -t) wird noch optional von python, git gebraucht
# Bei pacman -Qttd hingegen
pacgraph (--asexplicit) # Wird nicht getroffen, (Filter -d) ├─python (--asexplicit) # Wird nicht getroffen, (Filter -d) ├─inkscape (optional, --asdeps) # Wird getroffen, (Filter -tt) da von keinen Paket es eine direkte Abhängigkeit ist ├─imagemagick (optional, --asdeps) # Wird nicht getroffen, (Filter -tt) da es eine direkte Abhähigkeit von zbar ist. └─tk (optional --asdeps) # Wird getroffen, (Filter -tt) da es von keinem Paket eine Direkte Abähgigkeit ist.
pacgraph (--asdeps) # Wird getroffen, (Filter -d) ├─python (--asexplicit) # Wird nicht getroffen, (Filter -d) ├─inkscape (optional, --asdeps) # Wird getroffen, (Filter -tt) da von keinen Paket es eine direkte Abhängigkeit ist ├─imagemagick (optional, --asdeps) # Wird nicht getroffen, (Filter -tt) da es eine direkte Abhähigkeit von zbar ist. └─tk (optional --asdeps) # Wird getroffen, (Filter -tt) da es von keinem Paket eine Direkte Abähgigkeit ist.
# yay -Yc ist ein eine intelegentere Kombination aus beiden (-Qtd, -Qttd)
pacgraph (--asexplicit) # Wird nicht getroffen, (Da Paket erwünscht) ├─python (--asexplicit) # Muss nicht mehr geprüft werden, da das höhere Paket erwünscht ist ├─inkscape (optional, --asdeps) # Muss nicht mehr geprüft werden, da das höhere Paket erwünscht ist ├─imagemagick (optional, --asdeps) # Muss nicht mehr geprüft werden, da das höhere Paket erwünscht ist └─tk (optional --asdeps) # Muss nicht mehr geprüft werden, da das höhere Paket erwünscht ist
pacgraph (--asdeps) # Wird getroffen ├─python (--asexplicit) # Wird nicht getroffen ├─inkscape (optional, --asdeps) # Wird getroffen, geht hier tiefer und überüft denn tieferen zweig ob die Pakte dort auch weg können. ├─imagemagick (optional, --asdeps) # Wird nicht getroffen, da es eine Abhäigkeit von zbar ist. └─tk (optional --asdeps) # Wird nicht getroffen, weil es eine Optionale Abhägigkeit von python und git ist.
|
|
nteressant wäre ob es mittels expac eine Möglichkeit gibt zu schauen ob irgendein Paket aller installierten Pakete die optionale Abhängigkeit "xyz" hat...
|
|
Das wäre wirklich interessant und wäre am einfachsten umzusetzen, wenn man das Attribut "Optional für" eines Pakets mit expac abfragen könnte, aber genau dieses Feld kann expac leider nicht abfragen soweit ich weiß. Da muss ich dann ein wenig mehr Gehirnschmalz investieren, um eine Lösung zu finden. Aber nicht mehr heute Abend
LG
Sebastian
|
« Letzte Änderung: 25. September 2022, 09:41:27 von Sebastian » |
Gespeichert
|
Richtig um Hilfe bitten
|
|
|
Sebastian
YaBB God
Offline
Einträge: 521
|
|
Re:Pacman Datenbank Pflege
« Antwort #10 am: 25. September 2022, 10:20:33 »
|
|
Und da selbst mir eine unerkannte Abhängigkeit durchrutschen kann weswegen ich ein Paket das ich nicht mehr wiederbekomme lösche nur damit die Ausgabe von pacman -Qtd leer bleibt - ich dafür aber ein wichtiges aber selten benutztes altes Tool zerschossen habe: möchte ich die denen solche Erfahrungen noch nicht zu Teil geworden sind warnen...
|
|
Ich gehe davon aus, dass unbekannte Abhängigkeiten nur in Bauanleitungen im AUR schlummern. Und dass die Pakete aus dem Offizelen Arch Repo gut gepflegt sind. Falls ich also ein AUR Paket nutze das am Anfang nicht bauen möchte, weil eine Abhängigkeit fehlt, dann wird im besten fall der Maintainer kontaktiert, damit er das fixt. Wenn das nicht fruchtet bzw. es mir zu lange dauert, würde ich die fehlende Abhängigkeit manuell nachinstallieren als --asexplicit, damit ich weiß, dass ich dieses Paket aus einem bestimmten Grund installiert habe. Falls das AUR Paket, weil verweist eh keine Updates mehr erfährt, und ich wirklich auf diese nicht mehr gepflegte Software angewiesen bin bzw. nicht verzichten kann, dann würde ich das Paket sogar einmal neu bauen und das fehlende Paket als Abhängigkeit hinzufügen. Damit es mit der Datenbank wieder stimmig ist.
Die pacman Datenbank sehe ich quasi als mein Notizbuch an der Ort wo ich mir aufschreibe, weshalb ich bestimmte Pakete habe.
Der andere fall den du beschrieben hast, wenn ein Paket baut, weil man zufällig die fehlende Abhängigkeit installiert hat, ist natürlich um einiges schwieriger zu lösen. Das würde in der Tat mir erst auffallen, nachdem ich etwas deinstalliert habe, und ein Programm nicht mehr funktioniert. Da ich aber nicht jeden Tag neue Software installiere bzw. deinstalliere und beim Entfernen von Paketen nur immer ein paar Pakete sind, würde mir das doch relativ schnell auffallen (Vorteil eines schlanken Systems)
Für alle anderen die natürlich ein Riesensystem haben steigt die Komplexität immer weiter an und es kann immer mehr durchrutschen. Deswegen sind deine Anmerkungen und Einwände durchaus angebracht.
Nur damit man sich ein Bild machen kann wie komplex so ein System ist. habe ich mal ein Bild von meiner Datenbank angehangen.
Schriftgöße = größe eines Pakets Grün = Hauptpakete Orange = Abhängigkeiten
LG
Sebastian
|
Richtig um Hilfe bitten
|
|
|
Sebastian
YaBB God
Offline
Einträge: 521
|
|
Re:Pacman Datenbank Pflege
« Antwort #11 am: 26. September 2022, 18:28:54 »
|
|
@Andreas
Interessant wäre ob es mittels expac eine Möglichkeit gibt zu schauen ob irgendein Paket aller installierten Pakete die optionale Abhängigkeit "xyz" hat...
|
|
Ich hoffe, ich hatte dich richtig verstanden, dass du nach einer möglichkeit suchst zu erfahren, dass Paket X eine optionale Abhängigkeit von Y, Z usw. ist.
Wenn man ein einzelnes Paket mit pacman -Qi abfragt, dann steht diese Information in der Zeile "Optional für". Um diese Information weiterzuverarbeiten, habe ich eine Funktion geschrieben, die diese Information aus dieser Zeile extrahiert. Ist zwar nicht optimal, dass ich mit dem Frontend pacman gearbeitet habe, und nicht gleich mit libalpm, aber so tief wollte ich mich da jetzt auch nicht einarbeiten.
Übergibt man dieser Funktion ein Paketname (es gehen nur lokal installierte) dann bekommt man die installierten Pakte zurück wofür dies eine optionale Abhängigkeit ist, ist dies für keines eine optionale Abhängigkeit gibt die Funktion den Fehler Code 1 zurück. Übergibt man der Funktion nichts, dann fragt diese alle installierten Pakete ab, und man bekommt eine Liste von installierten Paketen zurück, die für irgendein installiertes Paket eine optionale Abhängigkeit darstellt.
#!/bin/bash
optf() { # Return the Optional for Packages from a Package declare LANG=C declare -a _pkg=("${@}")
declare -a _opt_for declare _opt_row="Optional[[:space:]]For.*" declare _object_optional_for_pattern="object#Optional For[[:space:]]*: " mapfile -t _pacman_output < <(pacman -Qi "${_pkg[@]}") for object in "${_pacman_output[@]}"; do if [[ "${object}" =~ ${_opt_row} && "${object}" == "${object#Optional For[[:space:]]*: None}" ]]; then _opt_for+=(${object#Optional For[[:space:]]*: }) fi done if [[ ${_opt_for[@]} ]]; then IFS=$'\n' _sorted=($(sort -u <<<"${_opt_for[*]}")) unset IFS printf "%s\n" "${_sorted[@]}" else return 1 fi }
|
|
Ich hoffe, sowas hattest du gemeint.
|
« Letzte Änderung: 26. September 2022, 18:34:54 von Sebastian » |
Gespeichert
|
Richtig um Hilfe bitten
|
|
|
Andreas
Administrator
Offline
Einträge: 1345
Linux von Innen
|
|
Re:Pacman Datenbank Pflege
« Antwort #12 am: 27. September 2022, 05:51:27 »
|
|
Hi Sebasziam
danke. Genau so etwas meinte ich. Preisfrage: Kann/darf es zwischen den Ausgaben von deinem Script (ohne Angabe eines Paketes) und pacman -Qtdq Überschneidungen geben? Nach meinem Verständnis eigentlich nicht. Entweder etwas ist "noch da und wird von nichts benötigt" - dann darf es bei der pacman... auftreten, nicht aber in deinem Script - oder es ist von irgendwas abgängig - dann darf es bei keinem auftreten. Aber dass es bei beiden auftritt wäre ein Widerspruch - oder denke ich da falsch?
LG Andreas
|
|
Gespeichert
|
Wissen ist das einzige Gut, das mehr wird, wenn man es teilt - wenn es Menschen gibt, die es teilen, und es Menschen gibt, die bereit sind, dieses Geschenk auch mit eigenem Einsatz anzunehmen.
Freiheit zu erkämpfen reicht nicht. Man muss sie auch verteidigen.
Ohne IT-Kompetenz ist man heutzutage ein willkommenes Opfer und Spielball anderer, egal, welches System oder Gerät man nutzt. Nur Wissen schützt vor Schaden!
|
|
|
Sebastian
YaBB God
Offline
Einträge: 521
|
|
Re:Pacman Datenbank Pflege
« Antwort #13 am: 27. September 2022, 15:27:34 »
|
|
Es kann dann immer noch zu Überschneidungen kommen. Ich demonstriere das mal an einem Beispiel:
Ausgend von disem Abhägigkeits Baum IR = installation reason dep = dependency opt = optional
dpkg1 (IR: dep) ├─dpkg2 (IR:dep, dep) │ ├─dpkg3 (IR: dep, dep) │ └─dpkg4 (IR: dep, opt) ├─dpkg3 (IR: dep, dep) └─dpkg4 (IR: dep, opt)
Was wird jetzt von pacman -Qtdq getroffen
dpkg1 (IR: dep) Treffer, Wird von keinem anderen Paket benötigt && Wurde nicht expilziert installiert ├─dpkg2 (IR:dep, dep) Kein Treffer, Wird noch von dpkg1 gebraucht. Erst wenn dpkg1 entfernt wurde wird es getroffen. yay -Yc erkennt sowas │ ├─dpkg3 (IR: dep, dep) Kein Treffer, wird auf dieser ebene noch von dpkg2 gebraucht und von dpkg1 eine ebene höher │ └─dpkg4 (IR: dep, opt) Kein Treffer, wird nicht von -Qtdq brücksichtigt da es eine otionale abhägigkeit ist. ├─dpkg3 (IR: dep, dep) Kein Treffer, wird noch von dpkg1/2 gebraucht, erst wenn dpkg1/2 entfernt wurden wird es getroffen. yay -Yc erkennt sowas └─dpkg4 (IR: dep, opt) Kein Treffer, optional wird nicht berücksichtigt.
Was würde jetzt von meiner Funktion getroffen:
dpkg1 (IR: dep) Treffer, da dpkg4 angibt eine optionale Abhägigkeit hierfür zu sein. ├─dpkg2 (IR:dep, dep) Treffer, dpkg4 gibt auch hier an eine Optionale abhäigkeit zu sein │ ├─dpkg3 (IR: dep, dep) Kein Treffer, Es gibt kein Paket das für dpkg3 Optional ist │ └─dpkg4 (IR: dep, opt) Kein Treffer, Es gibt kein Paket das für dpkg4 Optional ist ├─dpkg3 (IR: dep, dep) Kein Treffer, Es gibt kein Paket das für dpkg3 Optional ist └─dpkg4 (IR: dep, opt) Kein Treffer, Es gibt kein Paket das für dpkg4 Optional ist
|
|
Man erkennt also, dass dpkg1 in beiden Ausgaben vorkommen kann. Da Abhängigkeiten leider nicht linear sind, sondern Querverweise aufweisen können. Es sind sogar noch andere Konstellationen denkbar, da meine Funktion, wenn es alle Pakete abfragt, alle Paketnamen zurückgibt, für die es mindestens 1 optional installiertes Paket gibt, und dieses Paket wieder ist vielleicht eine normale Abhängigkeit von einem anderen Paket, das nicht mehr gebraucht wird. Dann hätten wir auch hierbei eine Überschneidung.
Datenbanken finde ich zwar sehr interessant, sie können einen aber auch den letzten Nerv rauben
Wenn du selbst mal herumprobieren möchtest. Hier das PKGBUILD für die Dummy Pakete, die lassen sich dann auch wieder leicht entfernen.
# Dummy PKG pkgbase=dpkg pkgname=(dpkg1 dpkg2 dpkg3 dpkg4) pkgver=1 pkgrel=1 pkgdesc="Dies ist ein Dummy Paket" arch=(any)
package_dpkg1(){ depends=(dpkg2 dpkg3) optdepends=(dpkg4) } package_dpkg2(){ depends=(dpkg3) optdepends=(dpkg4) } package_dpkg3(){ pkgdesc="${pkgdesc}" } package_dpkg4(){ pkgdesc="${pkgdesc}" }
|
|
|
|
Gespeichert
|
Richtig um Hilfe bitten
|
|
|
Andreas
Administrator
Offline
Einträge: 1345
Linux von Innen
|
|
Re:Pacman Datenbank Pflege
« Antwort #14 am: 27. September 2022, 18:31:13 »
|
|
OK - ich sehe die Möglichkeiten...
Das bedeutet im Rückschluss dass jeder, der sein System "von Grund auf" selbst installiert hat (also "Halb"-Profis oder mehr) mit den genannten Methoden ihre Paket-Datenbank schlank halten können. Alle, die eine "Fertig-Installation" (von wo auch immer) bekommen haben dürften aber an dieser Pflege scheitern.
Warum wählt jemand eine Vorinstallation durch jemand anders?
--> weil er es sich nicht selbst zutraut.
Wer es sich nicht selbst zutraut eine eigene Installation hinzubekommen wird aber an dieser Art der Paketdatenbankpflege scheitern.
Mein (ernst gemeinter) Tipp an diese Personengruppe:
Vergesst das Erreichen von "100 Punkten". Bevor ihr durch unbedachte Löschoperationen irgendwas schwer wiederherstellbares löscht: Lebt lieber mit der "Verschwendung" von ein paar hundert Megabytes (meinetwegen auch ain paar Gigabytes) Plattenspaces bevor ihr euch euer System zerlegt.
Mein System ist in der Zwischenzeit so komplex geworden dass ich sehr viel Herzblut investieren müsste um es so zu pflegen. Ich halte es da so wie mit unserem Garten: "Was ist Unkraut"? Lass es wachsen!"
Das Positive ist: Im Gegensatz zu einem Windows-System, das mit jedem solchen "Müll" zunehmend instabiler und unkontrollierbarer wird ist bei einem Linx-System der einzige negative Aspekt "Festplattenplatzverschwendung". Das dürfte bei den heutigen Plattenpreisen kein ernsthaftes Argument sein...
LG Andreas
|
|
Gespeichert
|
Wissen ist das einzige Gut, das mehr wird, wenn man es teilt - wenn es Menschen gibt, die es teilen, und es Menschen gibt, die bereit sind, dieses Geschenk auch mit eigenem Einsatz anzunehmen.
Freiheit zu erkämpfen reicht nicht. Man muss sie auch verteidigen.
Ohne IT-Kompetenz ist man heutzutage ein willkommenes Opfer und Spielball anderer, egal, welches System oder Gerät man nutzt. Nur Wissen schützt vor Schaden!
|
|
|
Seiten: [1] 2
|
|
|
|
|
|
|