Ubuntuで「apt-get autoremove」を処理する方法
（同様の質問/懸念のある20ページ以上をリストできます。しかし、解決策が見つかりませんでした。重複としてマークする前に、我慢してください。）
WindowsからLinux（Ubuntu）に切り替えたのは、ほぼ3週間です。私は自分のアプリケーションに適したツールを見つけようとしています。だから、私はLinuxでさまざまなアプリケーションを試してきました。その結果、apt-getを使用して多くのアプリケーションをインストール/削除しました。
これらのインストール/削除コマンドのいずれかの後、apt-getはapt-get autoremoveコマンドの実行を提案しました。そうすると、デスクトップアプリケーションの一部も削除され、デスクトップ環境の外観が完全に変更されたことに気付きました。私はLinuxの専門家ではないので、時間をかけて再インストールすることになりました！
そのとき、私はapt-get autoremoveを二度と使用しないことにしました。それから、私は探し回ってdeborphanに出会いました。これは、孤立パッケージの削除に推奨されていました。したがって、apt-get autoremoveを使用する代わりに、以下のコマンドを使用して不要なパッケージを削除しました。
Sudo deborphan --guess-all | xargs Sudo apt-get -y remove --purge
これは最近まで、Qt-Creatorがエラーcannot find -lGLでC++コードのコンパイルを停止していたので問題ありませんでした。 deborphanを使用する直前で問題ありませんでした。幸運なことに、libgl1-mesa-devパッケージを再インストールすることで修正できました。
残念ながら、これはdeborphanに対する私の信頼の終わりでもありました。
apt-get autoremoveとdeborphanのいずれも使用しなかった数日後、aptが削除を提案するパッケージの長いリストを以下に示します。
0 upgraded, 0 newly installed, 79 to remove and 0 not upgraded.> The following packages will be REMOVED: fonts-wine
geany-plugins-common gir1.2-evince-3.0 gir1.2-gconf-2.0
gir1.2-nautilus-3.0 gir1.2-poppler-0.18 libboost-atomic1.62-dev
libboost-atomic1.62.0 libboost-chrono1.62-dev libboost-chrono1.62.0
libboost-context1.62-dev libboost-context1.62.0
libboost-coroutine1.62-dev libboost-coroutine1.62.0
libboost-date-time1.62-dev libboost-date-time1.62.0
libboost-exception1.62-dev libboost-fiber1.62-dev
libboost-fiber1.62.0 libboost-filesystem1.62-dev
libboost-graph-parallel1.62-dev libboost-graph-parallel1.62.0
libboost-graph1.62-dev libboost-graph1.62.0 libboost-iostreams1.62-dev
libboost-locale1.62-dev libboost-locale1.62.0 libboost-log1.62-dev
libboost-log1.62.0 libboost-math1.62-dev libboost-math1.62.0
libboost-mpi-python1.62-dev libboost-mpi-python1.62.0
libboost-mpi1.62-dev libboost-mpi1.62.0
libboost-program-options1.62-dev libboost-program-options1.62.0
libboost-python1.62-dev libboost-python1.62.0
libboost-random1.62-dev libboost-regex1.62-dev
libboost-serialization1.62-dev libboost-serialization1.62.0
libboost-signals1.62-dev libboost-signals1.62.0
libboost-system1.62-dev libboost-test1.62-dev libboost-test1.62.0
libboost-thread1.62-dev libboost-timer1.62-dev libboost-timer1.62.0
libboost-type-erasure1.62-dev libboost-type-erasure1.62.0
libboost-wave1.62-dev libboost-wave1.62.0 libboost1.62-dev
libboost1.62-tools-dev libhwloc-dev libibverbs-dev libieee1284-3:i386
libnuma-dev libopenmpi-dev libpython3-dev libpython3.6-dev libwine
libwine:i386 linux-headers-4.13.0-21 linux-headers-4.13.0-21-generic
linux-image-4.13.0-21-generic linux-image-extra-4.13.0-21-generic
mc-data mpi-default-dev ocl-icd-libopencl1:i386 python-glade2
python3-dev python3.6-dev Thunderbird-locale-en wine32:i386 wine64
このリストを調べて、本当に必要なパッケージと削除してもよいパッケージを見つける時間も知識もありません。
また、apt-get autoremoveが本当に孤立していて削除するのが望ましくないものを判断できるように、すべてを「手動」としてマークしようとしました。 aptitude keep-allを使用しましたが、常にフリーズします。これは bug 修正されるはずですが、明らかにそうではないことがわかりました。
質問：すべてのパッケージとその依存関係を1つずつ確認する必要のない、Ubuntuで不要なアプリケーション/ライブラリを削除する最も安全な方法は何ですか？
自動削除のルールは実際には非常に簡単です。
あなたの質問に対する具体的な答えは、「Ubuntuで不要なアプリケーション/ライブラリを削除するための最も安全なアプローチで、すべてのパッケージとその依存関係を1つずつ確認する必要はありません」です：Aptに任せてください。 aptがどのように決定を下すかをよく理解すれば、それを行うことができます。ほとんどの新規ユーザーにとって、これは学習曲線の通常の部分です。それでは、Aptロジックについて説明しましょう。
あなたがusingパッケージであるかどうかはAptにはわかりません。それは精神的なものではありません。各パッケージの依存関係と、ユーザーが何を伝えたかだけを知っています。パッケージが自動削除（孤立）に適格であるためには、2つの基準を満たす必要があります：
autoとして適切にマークする必要があります（manualの代わりに）- いいえ
manualパッケージは、パッケージに直接的または間接的に依存しません。
ユーザーを混乱させる3つの複雑な動作があります。
Aptは、どのパッケージを明示的にインストールしたかを記憶し、それらのパッケージを
manualとマークします。他のすべての依存関係は、autoとマークされます。Ubuntuインストーラーは、新規インストール
manualですべての初期パッケージをマークします。これは、新しいユーザーがシステムの巨大なスラブを誤って削除しないようにするためです。カーネルパッケージの動作は、Ubuntu script-fuのビットにより若干異なります。
それだけです-2つのルールと3つの特別な動作。他のすべては単純な古いロジックです。
いくつかの一般的な例を見て、これらのルールと動作がどのように適用されるかを見てみましょう。
例＃1：Sudo apt install foo libfoo
libfooと呼ばれるものは、おそらくfooの依存関係であることは明らかです。そして、aptもそれを知っています。ただし、libfooをインストールするようにaptに明示的に指示しました。manualとマークされ、自動削除の対象にはなりません。代わりにSudo apt install fooのみを指定してaptに依存関係を計算させた場合、libfooは（適切に）autoとマークされ、fooが削除されると自動削除の対象になります。
例＃2：Sudo apt remove ubuntu-desktop
最小イメージ からUbuntuシステムを構築する場合、またはLAMPスタックまたは新しいデスクトップ環境afterを最初にインストールする場合、ubuntu-desktopなどのメタパッケージは素晴らしいです- 1つのコマンドでスタック全体。しかし、aptの観点から見てください：単一のmanualパッケージと数十（数百）のauto依存関係。別のアプリケーションを試したためにメタパッケージをアンインストールした瞬間...まあ、あなたはアイデアを得る。
解決策は、主要なトップレベルアプリケーションをmanualとして単純にマークすることです。
Sudo apt install foo // Even if foo is already installed
Sudo apt-mark manual foo // Does the same thing
Sudo apt-mark auto libfoo // Makes libfoo eligible for autoremoval someday when foo gets removed
Sudo apt remove foo // Apt will remove foo *regardless* of apt-mark
Apt-markingは、どのパッケージが自動削除の対象とならないトップレベルのアプリケーションであるかを単に伝えるだけであり、人間の愚行からそれらを保護するものではないことに注意してください。
ほとんどの人が自動削除リストを閲覧する簡単な方法は、単にトップレベルの主要なアプリケーションパッケージ-メールクライアント、Webブラウザ、 IDE、お気に入りのゲーム。 fooを探し、libfooを無視します。スリップして削除されたら、単に再インストールします。パッケージをインストールするようにシステムに指示すると、それがmanualとマークされることに注意してください。 ただし、、ソフトウェアをコンパイルして-devパッケージを使用するため、特定のユースケースはより複雑です。あなたにとって魔法の解決策はありません（ごめん）-どのパッケージがあなたにとって重要であるかを学ぶのに時間をかけなければなりません...他の人たちと同じように。
Caveat：これはすべてUbuntuリポジトリのdebパッケージに適用されます。他の場所からおかしなパッケージをたくさん追加する場合は、さらにパッケージハウスキーピングを行う必要があります。 aptには、pip、snap、flatpack、appimageソフトウェア、ダウンロードしたバイナリまたはスクリプト、またはコンパイルされたコードに関する知識も制御もありません。