Titel: Pacman Datenbank Pflege
Beitrag von: Sebastian am 23. September 2022, 07:52:43
Aus gegeben Anlass hat mich das Thema Paketverwaltung in Bezug auf Abhängigkeiten noch mehr interessiert.
Versichernd euch bei jedem Lösch/Deinstallations-Befehl, dass ihr wisst, wie dieser arbeitet (Hintergrundwissen) bzw. überprüft ganz genau, was dort deinstalliert werden soll. Im Zweifel brecht es lieber ab!
Einleitung
Mit der Zeit sammeln sich durch Installation/Deinstallationen von Paketen sogenannte verwaiste (English = orphans) Pakete im System an. Dies sind Pakete, die von keinem anderen Paket als Abhängigkeiten mehr gebraucht werden und laut vermerkten Installationsgrund nicht explizit installiert wurden. Oder anders ausgedrückt, der Benutzer hat in der Pacman Datenbank nicht angegeben, dass er dieses Paket ausdrücklich behalten möchte. Normalerweise wird der Installationsgrund von Pakete, die durch pacman interaktiv auf der Kommandozeile installiert werden, automatisch auf ausdrücklich installiert gesetzt. Es kann aber passieren, dass durch irgendwelche Gründe der Installationsgrund nicht auf ausdrücklich installiert gestellt wird.
Als Beispiel sei da ein damaliger Bug (https://github.com/Jguer/yay/issues/270) im AUR Helper YAY zu erwähnen. Der dafür sorgte, dass eine Zeit lang Pakete die mit diesem installiert wurden immer als Installationsgrund Installiert als Abhängigkeit eines anderen Pakets gesetzt wurde. Deswegen sollte man hin und wieder nachschauen, ob bei den verwaisten Pakten keine Pakte mit dabei sind, die man doch behalten möchte, und den Installationsgrund korrigieren.
Installationsgründe richtig setzten
Um diese verwaisten Pakete ausfindig zu machen, kann man folgenden Befehl verwenden:
Code:
Dieser Befehl fragt die locale pacman Datenbank ("-Q") nach nicht mehr von anderen gebrauchten Pakten ("-t"), die als Installationsgrund als Abhängigkeiten installiert wurden ab ("-d"). Die letzte Option "-q" bewirkt, dass nur die Paketnamen ohne Versionsnummern ausgeben werden.
Je nachdem wie lange man seine Datenbank schon nicht mehr gepflegt hat, kann diese Liste schon sehr lang sein. Was man nun tun sollte ist die Liste durchzugehen, und einmal nachschauen, ob dort Pakete mit dabei sind, die man unbedingt behalten möchte. Hat man so ein Paket gefunden, kann man den Installationsgrund des Pakets auf ausdrücklich installiert ändern.
Dafür nutzt man diesen Befehl:
Code:
pacman -D --asexplicit PAKETNAMEN...
|
|
Hat man sich vertan, so kann man mit diesem Befehl den Installationsgrund wieder zurück als Abhängigkeit setzten:
Code:
pacman -D --asdeps PAKETNAMEN...
|
|
Somit weis pacman welche Pakete erwünscht sind, und welche deinstalliert werden dürfen, wenn sie von keinem anderen Paket mehr gebraucht werden. Das macht man so lange, bis der Befehl pacman -Qtdq nur noch Pakete anzeigt, die man nicht haben möchte. Die restlichen angezeigten Pakete können dann deinstalliert werden, da diese von keinem anderen Paket mehr gebraucht werden, und man selbst diese auch nicht mehr haben möchte.
Tipp:
Wenn einem die vielen Paketnamen beim Aufräumen nichts sagen, so kann man sich ein wenig behelfen, indem man die kurze Beschreibung zu den Paketen mit einblenden lässt.
Dafür installiert man sich das Paket expac und benutzt dann folgenden Befehl:
Code:
pacman -Qtdq | expac "%! %n\t\t\t\t%d" -
|
|
Habt ihr hingegen überhaupt keine Lust richtig auszumisten, und euch ist Speicherplatz auch nicht so wichtig. Und möchtet vielleicht ab jetzt Ordnung halten, dann könntet ihr auch einfach alle gefunden Pakete als Installationsgrund "Ausdrücklich installiert" angeben. Dies würde ich aber nicht empfehlen
Das macht folgender Befehl:
Code:
pacman -Qtdq | sudo pacman -D --asexplicit -
|
|
Deinstallation:
Ist nun die pacman Datenbank wieder in Ordnung gebracht, so kann man nun die restlichen Pakete mit diesem Befehl deinstallieren:
Code:
pacman -Qtdq | pacman -Rns -
#bzw. als kürzere schreibweise
yay -Yc
|
|
Wichtig: Kontrolliert noch mal die Ausgabe, ob da doch noch ein Paket mit dabei ist, das ihr behalten wollt und korrigiert vorher noch mal den Installationsgrund. Bevor ihr mit dem Deinstallieren anfängt.
Tipp, um für die Zukunft sein System sauber zu halten:
Nachdem ihr euer System nun aufgeräumt habt und die Ausgabe von pacman -Qtdq bzw. yay -Yc leer ist, könnt ihr euch mit dem AUR Paket pacman-log-orphans-hook (https://aur.archlinux.org/packages/pacman-log-orphans-hook) daran erinnern lassen eure pacman Datenbank regelmäßig aufzuräumen.
In diesem Paket ist ein pacman Hook drin, der dafür sorgt, dass bei jeder Paket-installation/Upgrade/Deinstallation überprüft, ob es wieder neue sogenannte verwaiste Pakete gibt, die als Installationsgrund "als Abhängigkeit installiert" angegeben sind. Und macht euch darauf aufmerksam dies zu Entfernen oder den Installationsgrund anzugeben das ihr sie behalten wollt.
Somit bleibt auch in Zukunft euer System schön sauber. ;) |
Titel: Re:Pacman Datenbank Pflege
Beitrag von: Andreas 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:
Code:
[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)
|
Titel: Re:Pacman Datenbank Pflege
Beitrag von: Sebastian 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.
Code:
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
Code:
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. |
Titel: Re:Pacman Datenbank Pflege
Beitrag von: Andreas 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 |
Titel: Re:Pacman Datenbank Pflege
Beitrag von: Sebastian 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 (https://archlinux.org/groups/x86_64/base-devel/), 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.
Code:
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:
Code:
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.
Code:
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. |
Titel: Re:Pacman Datenbank Pflege
Beitrag von: Andreas 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 |
Titel: Re:Pacman Datenbank Pflege
Beitrag von: Sebastian 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 (https://archlinuxarm.org/packages/any/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 ;D
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 |
Titel: Re:Pacman Datenbank Pflege
Beitrag von: Andreas 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 |
Titel: Re:Pacman Datenbank Pflege
Beitrag von: Andreas 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 |
Titel: Re:Pacman Datenbank Pflege
Beitrag von: Sebastian 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:
Code:
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
Code:
-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:
Code:
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 |
Titel: Re:Pacman Datenbank Pflege
Beitrag von: Sebastian 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 |
Titel: Re:Pacman Datenbank Pflege
Beitrag von: Sebastian 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.
Code:
#!/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. |
Titel: Re:Pacman Datenbank Pflege
Beitrag von: Andreas 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 |
Titel: Re:Pacman Datenbank Pflege
Beitrag von: Sebastian am 27. September 2022, 15:27:34
Es kann dann immer noch zu Überschneidungen kommen. Ich demonstriere das mal an einem Beispiel:
Code:
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.
Code:
# 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}"
}
|
|
|
Titel: Re:Pacman Datenbank Pflege
Beitrag von: Andreas 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 |
Titel: Re:Pacman Datenbank Pflege
Beitrag von: Sebastian am 28. September 2022, 13:51:45
Da pflichte ich Andreas absolut bei. Man sollte schon in der Lage sein, sein System selbst aufzusetzen, denn das ist leichter als ein Verständnis über Paketabhängigkeiten und der Datenbank pflege aufzubauen. Zudem durch das selbst installieren seines Systems weiß man von Anfang an, was man installiert hat und baut somit die Paketdatenbank Stück für Stück selbst auf, sodass das Unkraut gleich im Keim erstickt werden kann bevor es überhandnimmt.
Man konnte durch unsere Diskussion hier auch gut nachvollziehen, wie komplex Paketabhängigkeiten werden können, deswegen ist es ganz wichtig vor jeder Lösch Operation, die eingesetzten Filter/Automaten zu verstehen, um abschätzen zu können, ob dadurch etwas kaputtgehen kann.
Wie Andreas auch schon sagte, wenn ihr diese Datenbankpflege nicht betreibt, kostest euch das nur Speicherplatz. Euer System wird entgegen zu Windows dadurch nicht langsamer, weil keine unnötigen Prozesse dadurch gestartet werden. Das einzige was mal passieren könnte wäre, dass sich ein Paket weigert sich installieren zu lassen, da es im Konflikt mit einem anderen ist, das nicht hätte sein müssen, weil man das Problem Paket eh nicht mehr brauch. Aber dann kann man ja immer noch Aufräumen. :)
Wenn man sich dem Thema Datenbankpflege trotz der Komplexität zugewannt hat, und diese auch versteht, dann wird man um einiges besser sich in seinem System auskennen, und man wird um einiges sicherer in der Wartung seines Systems. Bleibt also schön neugierig und probiert ruhig dinge einmal aus.Aber nicht auf euren produktiv System, sondern ein extra dafür gemachtes was im Notfall entsorgt werden kann. Es lohnt sich auf jeden Fall ;)
LG
Sebastian |
Titel: Re:Pacman Datenbank Pflege
Beitrag von: Sebastian am 12. Februar 2023, 19:24:50
@Andreas
Gute Neuigkeiten für deine Pacman Datenbank.
https://archlinux.org/news/switch-to-the-base-devel-meta-package-requires-manual-intervention/Switch to the base-devel meta package requires manual intervention
2023-02-12 - Robin Candau
On February 2nd, the base-devel package group has been replaced by a meta package of the same name.
If you installed the base-devel package group prior to this date, explicitly re-install it to get the new base-devel package installed on the system:
pacman -Syu base-devel
|
|
Die Pakete in der base-devel Gruppe, haben ein Meta-Package bekommen. Das Paket kannst jetzt installiert werden, um Abhähigkeiten zwischen den Paketen herzustellen. Die base-devel Gruppe wird demnach wie auch die base Gruppe in der nächsten Zeit verschwinden. Indem aus dem PKBUILDs der einzelnen Pakete die base-devel Gruppen Angabe entfernt wird.
Dadurch werden wieder ein paar Pakete mehr als Abhähigkeit durch das Meta Paket hergestellt.
@All
Noch ein Hinweis
Ich persönlich würde grundsätzlich eine Paket Gruppe niemals als --asdeps installieren. Warum? Weil alle Pakete in einer Gruppe als einzelenes Paket betrachtet werden. Bedeutet man installiert sich alle Pakete als --asdeps
Beispiel:
Code:
pacman -S --asdeps archlinux-tools
|
|
wäre das gleiche wie:
Code:
pacman -S --asdeps arch-rebuild-order arch-repro-status arch-signoff
|
|
Und man wollte ja schlisslich die Pakete aus der Gruppe haben, oder zumindest ein teil davon. Deswegen sollte der Installationsgrund --asexplicit sein.
LG
Sebastian |
Diskussions- und Newsboard der Linux Interessen Gruppe Suletuxe | Powered by YaBB SE
© 2001-2003, YaBB SE Dev Team. All Rights Reserved.
|