ソフトウェアをビルドするときにパッケージをビルドするために必要なライブラリ、バイナリなどだけをインストールする必要がある場合がありますが、アンインストールするのを忘れてしまうため、そうでないパッケージも一度に複数個クリーンアップする必要がある場合があります。削除したいです。
正確なパッケージを見つけるためにログファイルを解析するのは最適ではなく、パッケージが十分に古い場合は大きな苦痛になる可能性があります。これを容易にする方法はありますか？
答え1
私はこの問題に役立つaptitude（aptバイナリにはこの機能はありません）の機能であるユーザータグを使用することをお勧めします。パッケージのインストール時に--add-user-tagオプションを追加します。例:
sudo aptitude --add-user-tag build-dep-package build-dep package
削除するには、以下を使用してください。
sudo aptitude remove '?user-tag(build-dep-package)'
削除タグを使用することもできます--remove-user-tag build-dep-package。
しかし、これは問題を引き起こします。同じパッケージに2つのタグがあるとどうなりますか？さて、これが起こらないようにするには、and / not条件を使用してください。
sudo aptitude remove '?and(?user-tag(build-dep-package),?not(?user-tag(wanted-packages))'
ラベルの異なる複数のパッケージで作業するには、次のようにします。
sudo aptitude remove '?or(?user-tag(build-dep-package),?user-tag(wanted-packages)'
これは長期的に非常に便利です。現在アクティブなすべてのタグを一覧表示する方法が見つかりませんでした。
答え2
ブログ投稿でDavid Kalnischkiesの投稿を見つけました。 UNDO APT-GET BUILD-DEP（ビルド依存関係の削除）
知らない人のために言うと、Davidは2009年頃から主な管理者として活動してきたので、彼が何を言っているのかを知っています。
ドンクールト•3年前
このクレイジーなコマンドライン操作を試す前に、次のオプションを試してください。APT :: Get :: Build-Dep-Automatic
apt-get build-dep -o APT::Get::Build-Dep-Automatic=true srcpkg1 srcpkg2 …
これがうまくいき、永続的に維持したい場合： echo APT::Get::Build-Dep-Automatic "true" > /etc/apt/apt.conf.d/99markbuilddepauto
どのAPTバージョンに追加されたのかは覚えていませんが、少なくともUbuntuバージョンで使用できるほど古いことに違いありません。
ああ、記録だけで申し上げれば本当に言えないことです。これは、APTに付属のインストーラアプリがすでに提供しているapt-markと同じ機能を使用するための適性をインストールするためです。
しかし、いつものように、6時間のコーディングで5分間のマニュアルページを読む必要はありません。
だから、
apt-get build-dep -o APT::Get::Build-Dep-Automatic=true srcpkg1 srcpkg2...
おそらく合理的なアプローチです。このオプションが存在するかどうかわかりませんでした。現時点では、適切な文書にはありません。もしあれば更新します。
しかし、Debianのバグレポートも参照してください。適性: APT::Get::Build-Dep-Automatic は尊重されません。。タイトルはすべてを教えてくれます。
更新：テスト後に機能しないようです。私がやった
# apt-get build-dep -o APT::Get::Build-Dep-Automatic=true g++
それから
# apt-get autoremove
しかし、何も返しません。たぶん私は何かを逃したようです。今はこの回答を維持します。
/var/lib/apt/extended_statesアップデート2：パッケージにタグが正しく指定されていることを確認しましたAuto-Installed: 1。したがって、autoremove誤って使用しているようです。
アップデート3：試してみました
# apt-get build-dep -o APT::Get::Build-Dep-Automatic=true coreutils
そして今回は
# apt-get autoremove
正しく削除されましたdh-buildinfo gperf libacl1-dev libattr1-dev。
それでは、なぜ以前の試みは成功しなかったのでしょうか？わかりませんが、最上位パッケージが手動でインストールされたパッケージに必要なダミーパッケージを提供すると仮定します。だから
gcj-jre-headless
Provides: java-gcj-compat-headless, java-runtime-headless, java-virtual-machine, java1-runtime-headless, java2-runtime-headless, java5-runtime-headless
そして
ant
Depends: default-jre-headless | java5-runtime-headless | java6-runtime-headless | java7-runtime-headless, libxerces2-java
だからここに重複する部分がありますjava5-runtime-headless。つまり。結論 - これは不幸な選択の例です。
答え3
これは既存の開発パッケージには役立ちませんが、後で使用するには（パッケージmk-build-deps内）を使用して依存関係のメタパッケージを作成することを検討してください。devscripts
mk-build-deps利用可能なパッケージまたは対応する制御ファイルの名前のみが必要です。後者は、パッケージがまだ利用できない場合や新しい依存関係を追加する場合に便利です。
必要に応じて、生成されたメタパッケージ（および依存関係）をインストールできます。
通常どおりインストール後、マニュアルページで詳細を確認できます。