Rechercher des fichiers qui n'ont pas été installés par le gestionnaire de packages

Je voudrais obtenir une liste de tous les fichiers de mon système Gentoo Linux qui n'ont pas été installés par le gestionnaire de paquets (Portage). C'est parce que je veux garder mon système aussi propre que possible, en supprimant tous les fichiers inutiles qui traînent.

Permettez-moi de vous dire ce que j'ai essayé jusqu'à présent. Tout d'abord, je génère la liste de tous les fichiers appartenant à un paquet suivi par Portage:

equery files "*" | sort | uniq > portage.txt

Ensuite, je génère la liste de tous les fichiers sur mon système, à l'exception de ceux dont je ne me soucie pas:

find / \( -path /dev -o -path /proc -o -path /sys -o -path /media \
          -o -path /mnt -o -path /usr/portage -o -path /var/db/pkg \
          -o -path /var/www/localhost/htdocs -o -path /lib64/modules \
          -o -path /usr/src -o -path /var/cache -o -path /home \
          -o -path /root -o -path /run -o -path /var/run -o -path /var/tmp \
          -o -path /var/log -o -path /tmp -o -path /etc/config-archive \
          -o -path /usr/local/portage -o -path /boot \) -prune \
          -o -type f | sort | uniq > all.txt

Enfin, j'obtiens la liste de tous les fichiers qui ne sont pas suivis par Portage:

comm -13 portage.txt all.txt > extra.txt

Quelques statistiques:

wc -l portage.txt all.txt extra.txt
  127724 portage.txt
   78371 all.txt
    8438 extra.txt

Comme vous pouvez le voir, je reçois encore plus de huit mille fichiers supplémentaires. Je voudrais réduire ce nombre, afin de me concentrer davantage sur les fichiers qui doivent vraiment être supprimés.

J'ai remarqué qu'il extra.txty a des milliers de fichiers dans un petit nombre de répertoires, tels que /usr/lib64/gcc, /usr/lib64/python2.7et /usr/lib64/python3.2. Le /usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.3/crtbegin.ofichier, par exemple, n'est pas portage.txtdedans car, à sa place, il y en a /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/crtbegin.o. Sur mon système /usr/libest un lien symbolique vers /usr/lib64. Il semble donc que je dois gérer correctement les liens symboliques pour obtenir de meilleurs résultats. Peut-être en ajoutant portage.txttous les fichiers vers lesquels ils pointent. Je ne sais pas vraiment comment faire ça.

Aussi, pourquoi portage.txtest-il plus grand que all.txt? Cela ne devrait pas être le contraire puisque les fichiers suivis par Portage sont un sous-ensemble de tous les fichiers de mon système?

Enfin, est-ce que j'oublie tout autre emplacement de la findcommande qui devrait également être exclu?

Ce que vous cherchez pourrait être qfile. Il fait partie du app-portage/portage-utilspackage et fournit l'option -oou --orphans. Vous pouvez utiliser quelque chose comme

find /usr/bin | xargs -I{} qfile -o {}

pour obtenir une liste des fichiers orphelins dans /usr/bin.

Remarque: Malheureusement, qfiledans la version stable actuelle de portage-utils, ne prend pas en charge la lecture à partir de stdin, et la solution mentionnée dans la page de manuel de qfile qfile -o $(find /usr/bin)ne fonctionne pas si l'ensemble de résultats de recherche est grand, par conséquent nous devons contourner un peu, en utilisant xargs.

BTW, ce n'est pas quelque chose que j'ai moi-même trouvé, mais je l'ai trouvé sur Gossamer-Threads, un commentaire de Yvasilev .

IIRC, gentoo stocke les informations sur les paquets en texte brut (/ var / db / peut-être), la recherche directe peut être lente.

La meilleure façon de le faire est de créer une base de données sqlitedatabase (ou n'importe quelle base de données) pour tous les fichiers de package, puis de répertorier tous les fichiers sur votre système, de les rechercher un par un dans la base de données, s'ils ne sont pas trouvés, ils n'appartiennent pas à portage .

J'ai réussi à résoudre le problème lié aux liens symboliques en portage.txtexécutant la commande suivante:

equery files '*' | while read i; do readlink -e "${i}"; done | sort | uniq \
       > portage.txt

Cela sert à mettre dans portage.txtles fichiers vers lesquels les liens symboliques pointent, et non les liens symboliques eux-mêmes. Cela est nécessaire car la findcommande qui crée all.txtne répertorie aucun lien symbolique, mais uniquement les fichiers vers lesquels ils pointent, il y aurait donc beaucoup de faux positifs sinon. C'est une commande assez lente, car elle s'exécute readlinksur des milliers de fichiers, mais je n'ai pas pu trouver de meilleure solution. Toute suggestion est la bienvenue.

Une autre chose que j'ai compris (c'était plus facile) c'est pourquoi portage.txtétait plus grand que all.txt. Cela est principalement dû au fait que j'ai explicitement élagué le /usr/srcrépertoire et tous les fichiers en dessous des résultats de la findcommande, mais equeryles ai quand même répertoriés.

La dernière chose que j'ai faite, même si ce n'était pas la question, a été d'ignorer les trucs Python (principalement les __pycache__fichiers et les fichiers avec le suffixe .pycou .pyo):

grep '\(\.cpython-32\)\?\.py[co]$\|/__pycache__' candidates.txt \
     > candidates-bytecode.txt
sed -e 's/\(\.cpython-32\)\?\.py[co]$/.py/' \
    -e 's/\/__pycache__//' \
    candidates-bytecode.txt | sort | uniq \
    > candidates-bytecode-source.txt
comm -23 candidates-bytecode-source.txt portage.txt \
     > orphaned-bytecode.txt

De cette façon, je trace l'origine de tous les trucs Python et vérifie s'ils sont dedans portage.txt. Comme vous pouvez le voir, j'ai écrit la même expression régulière deux fois, une pour la grepcommande et l'autre pour la sedcommande, mais peut-être que cela peut être fait en une seule étape.