パッケージマネージャーによってインストールされなかったファイルを検索する

私の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

ご覧のように、私はまだ8千を超える余分なファイルを取得しています。本当に削除する必要のあるファイルにより焦点を当てるために、この数を減らしたいと思います。

私は中にいることに気づいた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コマンドから除外する必要がある他の場所を忘れてしまいましたか？

あなたが探しているのはかもしれませんqfile。これはapp-portage/portage-utilsパッケージの一部であり、オプション-oまたはを提供します--orphans。あなたは次のようなものを使うことができます

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

で孤立したファイルのリストを取得します/usr/bin。

備考：悲しいことに、qfileportage-utilsの現在の安定バージョンでは、stdinからの読み取りをサポートqfile -o $(find /usr/bin)していません。また、検索結果セットが大きい場合、qfileのmanページに記載されている解決策は機能しないため、回避する必要があります。少し使用してxargs。

ところで、これは私が思いついたものではありませんが、yvasilevのコメントであるgossamer-threadsで見つけました。

IIRC、gentooはパッケージ情報をプレーンテキスト（おそらく/ var / db /）で保存します。直接検索は遅くなる可能性があります。

そうするための最良の方法は、すべてのパッケージファイル用のsqlitedatabase（または任意のdb）を作成し、システム上のすべてのファイルをリストし、1つずつdbで検索します。見つからない場合、portageに属していません。 。

portage.txt次のコマンドを実行して、シンボリックリンクに関連する問題をなんとか修正しました。

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

これはportage.txt、シンボリックリンク自体ではなく、シンボリックリンクが指すファイルを配置するのに役立ちます。find作成するコマンドはall.txtシンボリックリンクを一覧表示せず、それらが指すファイルのみを一覧表示するために必要です。それ以外の場合、多くの誤検知が発生します。readlink何千ものファイルで実行されるため、これは非常に遅いコマンドですが、より良い解決策を見つけることができませんでした。どんな提案でも大歓迎です。

私が理解したもう1つのこと（これは簡単だった）は、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ます。ご覧のとおり、同じ正規表現を2回記述しました。1つはgrepコマンド用で、もう1つはコマンド用ですsedが、おそらく1つのステップで実行できます。