Найти файлы, которые не были установлены менеджером пакетов


8

Я хотел бы получить список всех файлов в моей системе Gentoo Linux, которые не были установлены менеджером пакетов (Portage). Это потому, что я хочу, чтобы моя система была как можно более чистой, удаляя все ненужные файлы.

Позвольте мне рассказать вам, что я пытался до сих пор. Прежде всего, я генерирую список всех файлов, которые принадлежат некоторому пакету, отслеживаемому Portage:

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

Затем я создаю список всех файлов в моей системе, кроме тех, которые мне не нужны:

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

Наконец, я получаю список всех файлов, которые не отслеживаются Portage:

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

Немного статистики:

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

Как видите, я все еще получаю более восьми тысяч дополнительных файлов. Я хотел бы уменьшить это число, чтобы больше сосредоточиться на файлах, которые действительно необходимо удалить.

Я заметил, что extra.txtтам есть тысячи файлов в небольшом количестве каталогов, таких как /usr/lib64/gcc, /usr/lib64/python2.7и /usr/lib64/python3.2. /usr/lib64/gcc/x86_64-pc-linux-gnu/4.6.3/crtbegin.oФайл, например, не в portage.txtпотому, что на его месте, есть /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/crtbegin.o. В моей системе /usr/libесть символическая ссылка на /usr/lib64. Так что, похоже, мне нужно правильно обрабатывать символические ссылки, чтобы получить лучшие результаты. Возможно, добавив во portage.txtвсе файлы, на которые они указывают. Я действительно не знаю, как это сделать.

Кроме того, почему portage.txtбольше, чем all.txt? Не должно быть наоборот, так как файлы, отслеживаемые Portage, являются подмножеством всех файлов в моей системе?

Наконец, я забываю любое другое место в findкоманде, которое также должно быть исключено?


1
«Это потому, что я хочу поддерживать свою систему как можно более чистой, удаляя все ненужные файлы, которые лежат вокруг». - Вы уже потратили свое время на это дешевле, чем потраченные впустую мегабайты дискового пространства? :)
Пой

Ну, я должен был сказать, что это также для поиска файлов, которые принадлежат пакету, который не был установлен через менеджер пакетов. Мне нужна была программа, но в последнее время не было доступно ebuild, и мне еще предстоит научиться правильно писать ebuild.
Франческо Турко

Это может быть полезно: us.generation-nt.com/answer/…
ed.

Ответы:


2

То, что вы ищете, может быть qfile. Он является частью app-portage/portage-utilsпакета и предоставляет опцию -oили --orphans. Вы можете использовать что-то вроде

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

чтобы получить список потерянных файлов в /usr/bin.

Замечание: К сожалению, qfileв текущей стабильной версии portage-utils не поддерживается чтение из stdin, и решение, упомянутое на man-странице qfile qfile -o $(find /usr/bin), не работает, если набор результатов поиска велик, поэтому мы должны обойти его немного, используя xargs.

Кстати, это не то, что я сам придумал, но я нашел это в тонких нитях, комментарий Ивасилева .


Gentoo не использует менеджер пакетов Debian.
vonbrand

1
Правда. Gentoo использует portage. Как и оригинальный вопрос, четко сформулированный. Кто хотел знать, как найти потерянные файлы в системе Debian?
luttztfz

0

IIRC, gentoo хранит информацию о пакете в виде простого текста (/ var / db / возможно), прямой поиск может быть медленным.

Лучший способ сделать это - создать sqlitedatabase (или любую другую базу данных) для всех файлов пакета, затем перечислить все файлы в вашей системе, посмотреть их в базе данных один за другим, если не найден, он не принадлежит portage ,


0

Мне удалось решить проблему, связанную с символическими ссылками portage.txt, выполнив следующую команду:

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

Это служит для размещения в portage.txtфайлах символических ссылок, а не самих символических ссылок. Это необходимо, потому что findкоманда, которая создает all.txt, не перечисляет никакую символическую ссылку, а только файлы, на которые они указывают, поэтому в противном случае было бы много ложных срабатываний. Это довольно медленная команда, так как она работает readlinkс тысячами файлов, но я не смог найти лучшего решения. Любое предложение приветствуется.

Еще одна вещь, которую я понял (это было проще), почему portage.txtбыл больше, чем all.txt. Это происходит главным образом из-за того, что я явно удалил /usr/srcкаталог и все файлы из результатов findкоманды, но equeryперечислил их независимо.

Последнее, что я сделал, даже если это не было вопросом, было игнорирование Python (в основном это __pycache__файлы и файлы с суффиксом .pycили .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

Таким образом, я отслеживаю происхождение всего материала Python и проверяю, есть ли он portage.txt. Как видите, я написал одно и то же регулярное выражение два раза, одно для grepкоманды, а другое для sedкоманды, но, возможно, это можно сделать всего за один шаг.


Вероятно, это было бы намного быстрее, просто используя cat /var/db/pkg/*/*/CONTENTS | sed -r 's/^... //; s/ ([0-9a-f]+ )[0-9]+$//; s/ -> .*$//'напрямую, а не удивительно медленный Pythonequery files '*'
Evi1M4chine
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.