Trova i file che non sono stati installati dal gestore pacchetti


8

Vorrei ottenere un elenco di tutti i file nel mio sistema Gentoo Linux che non sono stati installati dal gestore pacchetti (Portage). Questo perché voglio mantenere il mio sistema il più pulito possibile, rimuovendo tutti i file inutili in giro.

Lascia che ti dica cosa ho provato fino ad ora. Innanzitutto, generi l'elenco di tutti i file che appartengono ad alcuni pacchetti tracciati da Portage:

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

Quindi generi l'elenco di tutti i file sul mio sistema, ad eccezione di quelli che non mi interessano:

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

Infine, ottengo l'elenco di tutti i file che non sono monitorati da Portage:

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

Alcune statistiche:

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

Come vedi ho ancora più di otto mila file extra. Vorrei ridurre quel numero, al fine di concentrarmi maggiormente sui file che devono davvero essere eliminati.

Ho notato che extra.txtci sono migliaia di file in un piccolo numero di directory, come /usr/lib64/gcc, /usr/lib64/python2.7e /usr/lib64/python3.2. Il /usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.3/crtbegin.ofile, ad esempio, non è presente portage.txtperché, al suo posto, esiste /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/crtbegin.o. Sul mio sistema /usr/libè presente un collegamento simbolico a /usr/lib64. Quindi sembra che devo gestire correttamente i collegamenti simbolici per ottenere risultati migliori. Forse aggiungendo portage.txttutti i file che indicano. Non so davvero come farlo.

Inoltre, perché portage.txtè più grande di all.txt? Non dovrebbe essere il contrario poiché i file tracciati da Portage sono un sottoinsieme di tutti i file nel mio sistema?

Infine, sto dimenticando qualsiasi altra posizione nel findcomando che dovrebbe essere esclusa?


1
"Questo perché voglio mantenere il mio sistema il più pulito possibile, rimuovendo tutti i file inutili in giro." - è già il tuo tempo che hai speso per quei meno costosi megabyte di spazio su disco? :)
poige

Bene, avrei dovuto dire che è anche per trovare file che appartengono a un pacchetto che non è stato installato tramite il gestore pacchetti. Avevo bisogno di un programma ma non era disponibile alcun ebuild recente e devo ancora imparare a scrivere correttamente gli ebuild.
Francesco Turco,

Questo potrebbe essere utile: us.generation-nt.com/answer/…
ed.

Risposte:


2

Quello che stai cercando potrebbe essere qfile. Fa parte del app-portage/portage-utilspacchetto e fornisce l'opzione -oo --orphans. Puoi usare qualcosa di simile

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

per ottenere un elenco di file orfani in /usr/bin.

Nota: Sfortunatamente, qfilenell'attuale versione stabile di portage-utils, non supporta readin da stdin e la soluzione menzionata nella pagina man di qfile qfile -o $(find /usr/bin)non funziona se il set di risultati di ricerca è grande, quindi dobbiamo aggirare un un po ', usando xargs.

A proposito, questo non è qualcosa che mi è venuta in mente, ma l'ho trovato su gossamer-thread, un commento di yvasilev .


Gentoo non usa il gestore pacchetti Debian.
vonbrand,

1
Vero. Gentoo usa il portage. Come la domanda originale chiaramente indicata. Chi voleva sapere come trovare file orfani su un sistema Debian?
luttztfz,

0

IIRC, gentoo memorizza le informazioni sul pacchetto in testo semplice (/ var / db / forse), la ricerca diretta può essere lenta.

Il modo migliore per farlo è creare un sqlitedatabase (o qualunque db) per tutti i file del pacchetto, quindi elencare tutti i file sul proprio sistema, cercarli uno per uno nel db, se non trovato, non appartiene al portage .


0

Sono riuscito a risolvere il problema relativo ai collegamenti simbolici portage.txteseguendo il comando seguente:

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

Questo serve per inserire nei portage.txtfile i collegamenti simbolici a cui si riferiscono e non i collegamenti simbolici stessi. È necessario perché il findcomando che crea all.txtnon elenca alcun collegamento simbolico, ma solo i file a cui puntano, quindi altrimenti ci sarebbero molti falsi positivi. È un comando piuttosto lento, poiché funziona readlinksu migliaia di file, ma non sono riuscito a trovare una soluzione migliore. Qualsiasi suggerimento è il benvenuto.

Un'altra cosa che ho capito (era più facile) è perché portage.txtera più grande di all.txt. Ciò è principalmente dovuto al fatto che ho eliminato esplicitamente la /usr/srcdirectory e tutti i file sottostanti dai risultati del findcomando, ma equeryli ho elencati indipendentemente.

L'ultima cosa che ho fatto, anche se questo non era nella domanda, è stata ignorare le cose di Python (principalmente __pycache__file e file con il suffisso .pyco .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

In questo modo traccio l'origine di tutte le cose di Python e controllo se è presente portage.txt. Come puoi vedere, ho scritto la stessa espressione regolare due volte, una per il grepcomando e l'altra per il sedcomando, ma forse può essere eseguita in un solo passaggio.


Probabilmente sarebbe molto più veloce, semplicemente usando cat /var/db/pkg/*/*/CONTENTS | sed -r 's/^... //; s/ ([0-9a-f]+ )[0-9]+$//; s/ -> .*$//'direttamente, invece del sorprendentemente lento Pythonequery files '*'
Evi1M4chine
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.