パッケージマネージャがインストールしていないファイルを探す

パッケージマネージャがインストールしていないファイルを探す

パッケージマネージャ(Portage)によってインストールされていないGentoo Linuxシステムのすべてのファイルのリストを取得したいと思います。周囲の不要なファイルをすべて削除してシステムをできるだけクリーンにしたいからです。

これまで私が試したことを申し上げます。まず、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,000を超える追加ファイルがあります。実際に削除する必要があるファイルに集中するために、この数を減らしたいと思います。

、およびなど、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.oportage.txt/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/crtbegin.o/usr/lib/usr/lib64portage.txt

またなぜportage.txtより大きいかall.txt。 Portageが追跡するファイルは、私のシステム上のすべてのファイルのサブセットなので、反対方向にする必要はありませんか?

find最後に、コマンドから除外する必要がある他の場所を忘れましたか?

答え1

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

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

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

注:残念ながら、qfile現在の安定版portage-utilsではstdinでの読み込みはサポートされておらず、qfileのマニュアルページに記載されている解決策はルックアップ結果qfile -o $(find /usr/bin)セットが大きい場合は機能しないため、これを解決する必要があります。クリックして使用してくださいxargs

ところで、私はこれを自分で考えていませんでした。ヘアスプリングスレッド, yvasilevの口コミ

答え2

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。ご覧のとおり、同じ正規表現を2回(コマンドに対して1回grep、コマンドに対して1回)作成しましたが、sedたぶん1つのステップで完了することもできます。 。

答え3

IIRC、Gentooはパッケージ情報をプレーンテキスト(おそらく/ var / db /)として保存するため、直接検索するのが遅い場合があります。

最善の方法は、すべてのパッケージファイルに対してsqlitedatabase(または任意のデータベース)を作成し、システム上のすべてのファイルを一覧表示してデータベース内で1つずつ参照することです。見つからないとPortageに属しません。

関連情報