verwaiste Bibliotheken anzeigen und entfernen

H

holgerw

Guest
Hallo,

unter Debian gibt es mit deborphan ein mächtiges Werkzeug, mit welchem sich gezielt verwaiste Bibliotheken deinstallieren lassen. Wie schaut es da bei FreeBSD aus?
pkg-orphan gibt es nicht mehr, und pkg_cutleaves zeigt mir mein halbes System samt wichtiger Programme als entfernbar an. Gut, man kann exclude-Listen erstellen, die pkg_cutleaves dann nicht entfernt, aber das ist eine sehr zeitaufwändige Sache.

Kann mir hier jemand einen Hinweis geben?

Viele Grüße,
Holger
 
es gab früher mal pkg_libchk, halt noch mit dem alten pkg.
Allerdings finde ich das nun nicht in den Ports. Es kann sein, dass es Bestandteil von sysutils/bsdadminscripts gewesen ist und wenn nicht, dann könnte es doch in diesen *adminscripts etwas Brauchbares geben.
 
Euch ist aber schon klar dass die pkg_* Werkzeuge aus vergangenen Tagen stammen und wir seit pkgng mit 'pkg' arbeiten?
Ja.
Deshalb sagte ich auch "könnte".
"könnte" ja sein, dass das angepasst worden ist. Ich habe diese scripte lange nicht mehr benutzt und möchte mir das nun nicht ansehen.
Die Mechanismen sind ja ungefähr vergleichbar, evtl muss "nur" nach einer anderen Datenbank gesehen werden. Wie auch immer, "könnte vielleicht" helfen, mal dort nachzusehen.

Aber gut, dass du es nochmals deutlich erwähnst. Das hätte leicht überlesen werden können.
 
Kein Problem, Rechtfertigung ist nicht erforderlich. Ist lediglich eine schlimme Unart in Sachen Umgangsformen von mir dass ich kurze, knackige, hilfreiche Antworten gegenüber groben Mutmaßungen bevorzuge
 
Kein Problem, Rechtfertigung ist nicht erforderlich. Ist lediglich eine schlimme Unart in Sachen Umgangsformen von mir dass ich kurze, knackige, hilfreiche Antworten gegenüber groben Mutmaßungen bevorzuge

na, hätte ich sysutils/libchk vorher gekannt, hätte ich das natürlich auch irgendwann noch erwähnt ;)

Danke.
 
Das aktuelle pkg_libchk findet ihr hier: https://github.com/lonkamikaze/bsda2

Ich versuche gerade alle alten Funktionalitäten die noch einen Nutzen haben zu portieren. Da ist aber nicht viel übrig.

sysutils/libchk hat meiner Meinung nach einige Probleme. Das sind a) ist es relativ langsam (73s gegen 18s auf dem gleichen System). Und b) sind da die ganzen False positives. Auf meinem System meldet es einen Berg von Problemen die nicht existieren. Ich denke nicht, dass ich ein echtes Problem in dem Output bemerken würde.
 
Ich denke nicht, dass ich ein echtes Problem in dem Output bemerken würde.

habe vorhin drei verschiedene Durchläufe damit probiert und kann aus diesen wenigen Versuchen nur zustimmen. sysutils/libchk gibt einen nicht enden wollenden Bericht, den man sich mit sehr großem Aufwand dann manuell durcharbeiten müsste. Da will keine Freude aufkommen...
 
Hallo,

danke für Euer Interesse. Ich werde mir portsclean und pkg autoremove anschauen.

Viele Grüße,
Holger
 
Hallo,

auf meinem älteren System, das ich fast nur as den Ports gebaut habe, will mir ein pkg autoremove fast das ganze System entfernen. Ein portsclean -L hingegen zeigt mir folgendes an:

Code:
[root@biber /usr/home/holger]# portsclean -L
** /usr/local/lib/qt4/libphonon.so.4 is shadowed by /usr/local/lib/libphonon.so.4
        /usr/local/lib/libphonon.so.4   <- phonon-4.8.3
        /usr/local/lib/qt4/libphonon.so.4       <- phonon-4.8.3
--> Two packages install the same library in different directories!

** /usr/local/lib/qt4/libphononexperimental.so.4 is shadowed by /usr/local/lib/libphononexperimental.so.4
        /usr/local/lib/libphononexperimental.so.4       <- phonon-4.8.3
        /usr/local/lib/qt4/libphononexperimental.so.4   <- phonon-4.8.3
--> Two packages install the same library in different directories!

Mehr gibt es da nicht? Ein System, auf welchem ich nach dem Metapaket kde4 zahlreiche einzelnen Sachen von kde wie Spiele, Mail, Toys u.s.f. mit pkg entfernt habe, hat keinerlei verwaisten Pakete / Bibliotheken? Da stimmt meines Erachtens etwas nicht.

Viele Grüße,
Holger
 
habe vorhin drei verschiedene Durchläufe damit probiert und kann aus diesen wenigen Versuchen nur zustimmen. sysutils/libchk gibt einen nicht enden wollenden Bericht, den man sich mit sehr großem Aufwand dann manuell durcharbeiten müsste. Da will keine Freude aufkommen...
Dito ...
 
Und nun mal ein Beispiel:
Ich habe per pkg alle KDE Spiele, darunter auch kmahjongg entfernt. Wenn ich unter Debian GNU/LInux nun deborphan ausführen würde, zeigte mir dieses die verwaisten Pakete libkdegames und libkmahjongg als entfernbar an.

Nun unter FreeBSD:
Code:
[holger@biber /usr/local/lib]$ ls libk*|grep games
libkdegames.so
libkdegames.so.6
libkdegames.so.6.1.0
libkdegamesprivate.so
libkdegamesprivate.so.1
libkdegamesprivate.so.1.0.0

Da mal schauen, was von libkdegames noch abhängt auf meinem System:
Code:
[root@biber /usr/local/lib]# pkg delete libkdegames
Checking integrity... done (0 conflicting)
Deinstallation has been requested for the following 2 packages (of 0 packages in the universe):

Installed packages to be REMOVED:
        libkdegames-4.14.3_1
        libkmahjongg-4.14.3_1
Da hier nur eine weitere verwaiste Bibliothek libkmahjongg entfernt wird: Warum zeigt mir portsclean -L diese zwei Pakete nicht als verwaist an?

Ich bin also weiter auf der Suche nach einer deborphan-Alternative unter FreeBSD.

Viele Grüße,
Holger

P.S.: Mein Hinweis auf deborpahn dient lediglich der genauen Beschreibung, was ich möchte. Wenn es unter FreeBSD ein solches Werkzeug nicht gibt, ist das für mich weder schlimm noch eine Kritik wie "Debian hat bessere Werkzeuge" :)
 
pkg verlässt sich darauf, dass Pakete korrekt als "automatisch installiert" markiert sind. Installierst du ein Paket manuell, wird es als "nicht automatisch" gekennzeichnet. Alle Abhängigkeiten, die es nachzieht, sind im Umkehrschluss "automatisch". pkg noauto gibt dir eine Liste aller nicht automatisch, also manuell, installierten Pakete aus. Davon entfernst du die nicht mehr benötigten, anschließend wird pkg autoremove ausgeführt, um überflüssige automatisch installierte Pakete zu entfernen. Problematisch wird es, wenn die "automatisch installiert" Markierungen nicht mehr stimmen. Man kann es zwar mit pkg set -A 1 $paketname korrigieren, aber das ist recht aufwändig. In dem Fall kann man sich echte Orphans mit pkg query -e "%?d = 0" %n ausgeben lassen und sie von hand in pkg remove füttern. Falls jemand motiviert ist, könnte man das auch leicht verscripten.
 
Code:
==> pkg query -e "%?d = 0" %n

CoinMP
alsa-lib
babl
boehm-gc
ca_root_nss
cd-discid
cdparanoia
clucene
compositeproto
cscope
ctags
cvsps
cyrus-sasl
damageproto
db5
de-freebsd-doc
dialog4ports
dmidecode
dmxproto
dri2proto
e2fsprogs-libuuid
easy-rsa
en-freebsd-doc
expat
faad2
fixesproto
font-alias
font-util
fontcacheproto
fontsproto
freetype2
fribidi
fusefs-libs
gcc-ecj
giflib
glproto
gnome-pty-helper
gnome_subr
graphite2
gsfonts
hicolor-icon-theme
icu
id3lib
ilmbase
indexinfo
inputproto
java-zoneinfo
javavmwrapper
jbigkit
jpeg-turbo
kbproto
ladspa
lame
libao
libart_lgpl
libaudiofile
libcddb
libdaemon
libdevq
libdvdread
libedit
libevent2
libexttextcat
libfilezilla
libfpx
libiconv
libid3tag
libijs
libinotify
libltdl
liblz4
libmad
libmspack
libogg
libpaper
libpotrace
libproxy
libpthread-stubs
libressl
librevenge
librtmp
libsigc++
libsigsegv
libspiro
libsunacl
libvolume_id
libvpx
libx264
libxml2
libyaml
linux_base-c6
lp_solve
lzo2
npth
nspr
o3read
opencv-core
openldap-client
orc
pam_helper
pciids
pcre
perl5
pixman
pkg
pkgconf
png
poppler-data
portmaster
powerdxx
printproto
pugixml
pv
pygobject3-common
qt4-doc
randrproto
recordproto
renderproto
rsync
scrnsaverproto
slim-themes
smartmontools
soundtouch
speexdsp
sqlite3
svgalib
taglib
tcl86
tex-libtexlua
tex-libtexluajit
unzip
vbindiff
videoproto
wavpack
weblint
xbitmaps
xcursor-themes
xextproto
xf86dgaproto
xf86miscproto
xf86vidmodeproto
xineramaproto
xmlcatmgr
xorg-docs
xproto
xtrans
xvid
yajl
zziplib

Davon sind mindestens:
cyrus-sasl
hicolor-icon-theme
lame
pcre
perl5
pixman
pkg
pkgconf
png
poppler-data
portmaster
powerdxx
pv
rsync
slim-themes
smartmontools
unzip


etwas, was ich nicht einfach wegwerfen möchte.
Nun ist zumindest powerdxx mit portmaster installiert.

Ihr solltet das Script also lieber interactiv machen oder noch besser, eine Option ein solches Paket als "nicht automatisch" zu kennzeichnen, bevor die Löschorgie beginnt und man nachher den Verbandskasten suchen muß. :D
 
Hallo,

danke für Eure Hinweise und weiter gehenden Bemühungen (sehr gutes Forum und auch beteiligte Entwickler hier nehmen überhaupt nichts krumm, was meiner Erfahrung nach leider auch ganz anders sein kann).

Viele Grüße,
Holger
 
Hallo @Yamagi,

ich habe mir mal die Liste angeschaut von pkg noauto
Die ausgegebenen Pakete sind für mich alle wichtig, daher habe ich mal folgendes gemacht:
pkg noauto > paketliste
pkg set -A 1 $(cat 'paketliste')

Dann die 30 Pakete jeweils mit y abnicken. Vermutlich hätte ich das auch per pkg set -A -y automatisieren können.

Wenn ich nun ein pkg autoremove ausführe, entspricht das fast einem pkg delete -a, es sollen über 900 Pakete entfernt werden. Aber eigentlich ist das von der "pkg-Logik" her ja auch richtig, autoremove heißt, alles automatisch installierte wieder entfernen. Alle nicht zu entfernenden Pakte müssen also als "von Hand installiert" markiert werden, dann fasst ein autoremove diese Pakete nicht mehr an. Das ist bei Debians dpkg ähnlich.

Wie kann ich denn nun eine Liste mit allen als automatisch-installiert markierten Paketen bekommen, um diese dann per pkg set -A 0 $(cat 'paketliste') als "von Hand installiert" zu marlkieren? pkg auto zeigt mir nämlch nicht nur solche Pakete an, sondern ist ein alias zu pkg autoremove

Folgendes möchte ich machen:
Liste mir alle automatisch-installiert markierten Pakete auf (? / pkg noauto listet nur, pkg auto macht aber noch mehr)
leite sie in eine Datei um (ist mir klar)
und markiere dann alle aus der Datei ausgelesenen Pakete als "von Hand installiert" (ist mir klar)

Viele Grüße,
Holger
 
autoremove heißt, alles automatisch installierte wieder entfernen

nein, denn:
Code:
PKG-AUTOREMOVE(8)       FreeBSD System Manager's Manual      PKG-AUTOREMOVE(8)

NAME
     pkg autoremove -- removes orphan packages
...
...
DESCRIPTION
     pkg autoremove is used for removing orphan packages, which were installed
     during dependency resolution and are no longer needed.
...

Zumindest hat es mir bisher noch nie alle automatisch installierten Pakte entfernt.
Mal Zahlen. pkg noauto zeigt mir die etwa 140 Pakete, die ich von Hand zur Installation ausgewählt hatte. Insgesamt finde ich etwa 900 installierte Pakete auf meinem System. Die Differenz sind logischerweise die automatisch installierten Pakete und da sind bei weitem die meisten. Wenn ich etwa VLC oder k3b installiere, bekomme ich ja automatisch eine Menge an Abhängigkeiten zusätzlich geliefert, die ich eben nicht manuell angebe.

pkg noauto | xargs -o pkg info -qo
(mit Befehlen in Unix kämpfe ich immer noch, aber das Ergebnis des oben genannten ist jedenfalls das, was ich möchte)
Das gibt eine Liste, die genau die manuell installierten Pakete in einer Form zeigt, die man dann zur Wiederholung dieser Installation benutzen könnte.

pkg info -qo
Gibt ja eine komplette Liste aller installierten Pakete.

Die Differenz aus beiden Listen müsste also genau die Liste aller automatisch installierten Pakete sein.
Diese Differenz kann man einfach mittels eines Scripts und direktem Vergleich herbeiführen. Man kann die Listen mittels sort(1) ordnen und mittels diff(1) vergleichen. In meinem Fall (wie gesagt mit Unix-Befehlen habe ich es nicht so) musste ich die Ausgabe von diff dann noch mit grep(1) filtern.
Code:
pit@senyo ~:- > pkg noauto | xargs -o pkg info -qo | sort -u > liste-1
pit@senyo ~:- > wc -l liste-1
     137 liste-1
pit@senyo ~:- > pkg info -qo | sort -u > liste-2
pit@senyo ~:- > wc -l liste-2
     898 liste-2
pit@senyo ~:- > diff -an liste-1 liste-2 | grep \/ > liste-3
pit@senyo ~:- > wc -l liste-3
     761 liste-3

Code:
PKG-SET(8)              FreeBSD System Manager's Manual             PKG-SET(8)
...
...
OPTIONS
     The following options are supported by pkg set:

     -A 01, --automatic 01
                Set automatic flag for the package: 0 is not automatic, 1 is
                automatic.  This affects the operation of pkg-autoremove(8).
Da du nun alle manuellen Pakete auf Automatik gesetzt hast, kann pkg die beiden Gruppen nicht mehr voneinander unterscheiden.

pkg auto ist meiner Ansicht nach eine Abkürzung für pkg autoremove (ahja, schreibst du ja auch), ist also nicht auf der gleichen Ebene, wie pkg noauto, das ja Information liefert aber nicht manipuliert.
 
Sollten sich veraltete Bibliotheken auf FreeBSD nicht automatisch unter
Code:
/usr/local/lib/compat/
versammeln?

Diese Versammlung der veralteten Bibliotheken dort kann man ja gelegentlich mal auflösen, aber dann muss man eventuell auch mal einige bis viele Ports neubauen.
Oder bei Nutzung des alten portupgrade Werkzeugs schaltet man mit dem Schalter -u (--uninstall-shlibs Do not preserve old shared libraries) das aufheben alter Bibliotheken ab. Da kann dann das pkg_libcheck Werkzeug aus den sysutils/bsdadminscripts von Kamikaze sehr nützlich sein, um Ports zu finden, die durch das nichtbehalten alter Bibliotheken dann neu gebaut werden müssen.

Und was das FreeBSD Basissystem betrifft, also FreeBSD höchstselbst, da gibt es:
Code:
make check-old
make delete-old
make delete-old-libs
Siehe auch hier im FreeBSD Handbuch Anschnur:
https://www.freebsd.org/doc/de_DE.ISO8859-1/books/handbook/make-delete-old.html
Auch da muss man dann damit rechnen anschließend einiges an installierten Ports eventuell neubauen zu müssen.
 
Korrektur und Nachtrag:
das Werkzeug heißt:
Code:
pkg_libchk

Außerdem gehört zum portupgrade Werkzeugsatz auch noch das Werkzeug portsclean dazu, das kann mit dem Schalter -L folgendes:
-L
--libclean Clean out old, duplicate and/or orphaned shared libraries.

portsclean first deletes duplicate shared libraries where
appropriate, then puts away old and orphaned shared
libaries to /usr/local/lib/compat/pkg updating symlinks
properly. To keep binaries working, ldconfig(8) is run
after each library deletion or move.

portsclean is so wise you can safely run it without turn-
ing -i on. However, if you want to do further cleanup,
specify the flag to be asked on possibly unneeded
libraries too.

You can use the sysutils/libchk port to check which
library is linked with which binaries.
Mehr info zu portsclean gibt es in der man page:
http://www.freebsd.org/cgi/man.cgi?...se-ports&query=portsclean&sourceid=opensearch

Unter /usr/local/lib/compat/ finden sich auch die Bibliotheken die durch die misc/compat*x Pakete installiert werden, falls man binary Kompatibiltität zu älteren FreeBSD Versionen haben möchte.
Kann man sich auch leicht anschauen mit:
Code:
pkg which /usr/local/lib/compat/*
Veraltete shlibs für Anwendungen finden sich im Unterverzeichnis pkg unter /usr/local/lib/compat/.

Der portupgrade Werkzeugsatz ist ein ziemlich alter Werkzeugsatz. Ich benutze den schon lange, es gibt neuere Werkzeuge und mittlerweile auch das pkg Werkzeug für die Binarypakete.

Würde ich pkg autoremove benutzen, dann gäbe es wohl die Desktop-Apokalypse. Zwar würde FreeBSD immer noch laufen, aber das Desktop wäre futsch. Man könnte wohl die Liste speichern, was pkg autoremove alles löschen wollen würde, um es mal in Ruhe zu Fuß durchzugehen und genau nachschauen, ob man davon etwas von Hand entfernen kann. Aber blindlings einfach dem Automatismus vertrauen würde ich nicht, denn ich sehe es schon, dass es vieles entfernen will, was ich behalten will.
 
Code:
pit@senyo ~:-# pkg autoremove -n
Checking integrity... done (0 conflicting)
Nothing to do.

ich will versuchen, das zu verstehen. Wieso gibt es da solch einen Unterschied zu mir?

Also, mein System ist relativ neu aufgesetzt und ein 10.3-RELEASE und noch nie was anderes gewesen.
Wie oben gezeigt, wurden mir zusätzlich zu den etwa 140 manuell installierten Paketen nochmal etwa 750 automatisch hinzu installiert.
pkg autoremove findet nun gar nichts, hatte aber irgendwann mal einige Pakete entfernt. Das waren geschätzt vielleicht ein Dutzend und ich vermute, dass es sich um ungültig gewordene Versionen von etwas gehandelt hatte, das ich wirklich auch nicht mehr brauchte. Ich hatte das nicht weiter beachtet und stelle auch keine Beeinträchtigung fest.
Das System war zunächst vollkommen aus Paketen installiert und nur da, wo ich einen Bedarf sah (was hauptsächlich wegen unterschiedlicher Optionen der Fall ist, wie etwa "ffmpeg mit mp3" oder VLC mit Qt4 oder solche Sachen), da benutzte ich die Ports und zwar direkt und ohne Werkzeuge, wie portmaster oder portupgrade. Es sind nur etwa fünf einzelne ports, da lohnt sich kein Werkzeug. Welche das sind, sehe ich bei einem pkg upgrade, denn sie sind natürlich mit einem lock versehen, um nicht versehentllich mit "falschen" Optionen wieder als Paket zu kommen.

portupgrade benutzte ja früher eine andere Paket-Datenbank. Oder eben eine Ports-Datenbank. Und das alte pkg hatte eine Paket-Datenbank. Sofern ich das erinnere, lagen hierin ja auch die großen Probleme bei Mischinstallationen zwischen Paketen und Ports.
Mit dem neuen pkg(ng) ist das ja umgestellt und verbessert worden. Es gibt eine neue Paket-Datenbank und wenn ich das recht verstanden habe, lernt die auch, wenn ein Port installiert worden ist.
Evtl merkt sie es nicht oder nicht korrekt, wenn die alten Werkzeuge wie portupgrade oder portsmaster benutzt werden?
Oder kann der Unterschied mit den vielen (falschen) Treffern bei euch daher kommen, dass die Systeme aus alten Systemen (mit altem pkg) hochgezogen worden sind und es dabei dann einen Kuddel-Muddel gab?

Es kommt mir jedenfalls seltsam vor, dass es derart unterschiedlich aussehen kann und pkg autoremove mein Freund ist und bei euch eher feindlich auftritt.
 
Den /usr/ports/INDEX-$VERSION benutzt portupgrade immer noch, aber es trägt dann beim installieren die Pakete in die sqlite Datenbank vom pkg(ng) ein.
 
In dem Fall kann man sich echte Orphans mit pkg query -e "%?d = 0" %n ausgeben lassen

Nun habe ich mir das eine Weile angesehen und denke, dass mit diesem query solche Pakete angezeigt werden, die keine weiteren Abhängigkeiten fordern.
Damit fallen darunter auch solche, wie etwa multimedia/x265, die nur eine lib bringen, aber keine anderen fordern.
In meinem Verständnis ist das nicht mit verwaist gemeint. Aber vielleicht sollten wir uns darüber noch einigen, was das überhaupt meint.
Für mich sind verwaiste libs (oder auch andere Teile eines Programms) solche Überbleibsel, die zwar noch auf dem PC vorhanden sind, aber von keinem derzeit installierten Programm benötigt werden.
Man kann vielleicht streng sagen, dass ich multimedia/x265 getrost löschen kann, denn es bringt ja nur eine lib mit und wenn ich das Programm lösche, wird die auch nicht mehr gebraucht. Ich sehe aber nicht, ob vielleicht ein anderes Programm diese lib auch noch haben möchte. Das kann ich vielleicht nur aus dem Automatik-Status ablesen, weil der mir sagt, ob das Programm eben von einem anderen automatisch installiert worden ist (pkg query %a).
In einem kurzen Test kann ich so die Anzahl der nicht automatisch installierten Programme ohne Abhängigkeiten bei mir auf 19 reduzieren, während insgesamt 182 Programme ohne Abhängigkeiten gelistet werden. Die 19 habe ich mir noch nicht weiter angesehen, ich habe nur die Ausgabe auf "0" oder "1" gezählt, nicht die Namen dargestellt.
 
Zurück
Oben