web-dev-qa-db-ja.com

アプリケーションを完全に削除する正しい方法は何ですか？

このような情報をネットで検索し、次のようなさまざまなコマンドラインを見つけました。

Sudo apt-get remove application
Sudo apt-get remove application*

Sudo apt-get remove --purge application
Sudo apt-get remove --purge application*

Sudo apt-get purge application
Sudo apt-get purge application*

だから、正しい方法は何ですか？その「*」を使用する必要がありますか？

その後、次のコマンドも見つけました。

Sudo updatedb
Sudo locate application
Sudo rm -rf (file/folder name)
command-linepackage-management
541
user48949

  • apt-get remove packagename

    バイナリは削除されますが、パッケージの構成ファイルまたはデータファイルは削除されませんpackagename。また、インストール時に依存関係がインストールされたままになります。

  • apt-get purge packagenameまたはapt-get remove --purge packagename

    パッケージpackagenameに関する約everythingを削除しますが、インストール時にインストールされた依存関係は削除しません。両方のコマンドは同等です。

    設定を台無しにしてしまったため、アプリケーションを「最初からやり直したい」ときに特に便利です。ただし、ユーザーのホームディレクトリ（通常は非表示フォルダー）にある構成ファイルやデータファイルは削除されません。これらを削除する簡単な方法はありません。

  • apt-get autoremove

    孤立したパッケージ、つまり依存関係としてインストールされていたが、もはやインストールされていないインストール済みパッケージを削除します。不要になった依存関係がインストールされていたパッケージを削除した後、これを使用します。

  • aptitude remove packagenameまたはaptitude purge packagename（同様）

    また、packagename onで必要であったが、残りのパッケージでは必要ない他のパッケージを削除しようとします。 aptitudeは、インストールしたパッケージの依存関係情報のみを記憶することに注意してください。

そして、もっとたくさんあります。下位レベルのdpkg-コマンドを使用（高度）したり、Muon、Synaptic、Software CenterなどのGUIツールを使用したりできますアプリケーションを削除したり、他のパッケージ管理と対話するタスク。

見つけたリストは単なる例です。アクションを受け入れる前に、意味を理解し、やりたいことを確認してください（提案されたアクションを実際に実行する前にYを押す必要があります）。

質問のアスタリスクバージョンはおそらく間違っています; apt-getは、シェルとしてglobパターンではなく、正規表現を受け入れます。それで何が起こる

Sudo apt-get remove application*

次のとおりです。

  1. シェルは、現在のディレクトリ内のファイルを見てapplication*を展開しようとします。 （通常の場合）何も検出されない場合、グロブパターンを変更せずに返します（ここでbashがデフォルトの動作である場合--- zshはエラーになります）。

  2. apt-getは、名前が正規表現application*を満たす文字列を含むパッケージを削除します。つまり、applicatioに任意の数字が続きますof n：applicatio、application、applicationn、libapplicatioなど.

  3. これがどのように危険であるかを確認するには、（二重の安全のためにルートなしで）apt-get -s remove "wine*"（-sはそれを行う代わりにシミュレートします）を試してください。その名前と依存する、ほぼシステム全体で「勝つ」...

おそらく、意図されたコマンドは本当に

 Sudo apt-get remove "^application.*"

（引用符とドットに注意してください）名前がapplicationで始まるすべてのパッケージを削除します。

これらのコマンド、

Sudo updatedb                  # <-- updates the locate database (index). harmless
Sudo locate application        # <-- locates the file 'application'. harmless
Sudo rm -rf (file/folder name) # <-- removes files/dirs recursively. dangerous.

パッケージ管理の範囲外です。パッケージマネージャーを使用せずにパッケージに属するファイルを削除しないでください！混乱してしまい、wrongやり方になります。

ファイルがどのパッケージに属しているかわからない場合は、これを試してください：

dpkg -S /path/to/file
697
gertvdijk

Ubuntu 12.04以降の場合、正しい方法は次のとおりです。

Sudo apt-get --purge autoremove packagename

詳細は こちら です。

packagename*を使用しないでください。意図しないパッケージが削除され、解決するよりも多くの問題が発生する可能性があります。または、必要な場合は、少なくとも最初に-s、--simulate、--dry-runフラグを付けて実行し、実行せずに正確に何が実行されるかを確認します。

109
Kurtosis

次のコマンドを使用できます。

Sudo apt-get purge --auto-remove packagename

必要なパッケージと、それらのパッケージと共にインストールされる依存関係を削除します。 --auto-removeオプション（autoremoveのエイリアス）は、Sudo apt-get autoremoveと同様に機能します。このコマンドを使用すると、単一のコマンドを実行できます。

Sudo apt-get purge --auto-remove packagename

の代わりに：

Sudo apt-get purge packagename
Sudo apt-get autoremove
19
pl_rock

Sudo apt-get remove --purge applicationまたはSudo apt-get remove applicationsの99％を安全に使用できます。 purgeフラグを使用すると、すべての構成ファイルも削除されます。上記のアプリケーションを再インストールするかどうかに応じて、必要な場合とそうでない場合があります。 application*は、applicationで始まるすべてのアプリケーションに一致します。これらは通常、削除するメインアプリケーションのプラグイン、追加機能などです。つまり.

Sudo apt-get remove gedit*

gedit、gedit-plugins、およびgedit-commonを削除します。ほとんどのプラグイン/関連プログラムはメインアプリケーションに依存しており、メインアプリケーションをアンインストールすると自動的に削除（または削除マーク）されるため、通常、これを行う必要はありません。

最後のコマンドは、乱雑なアンインストーラーがあることがわかっているアプリケーションから残り物を削除することです。アプリケーションの残りを削除するだけです。

7
reverendj1

パッケージを削除する際にいくつかのエラーメッセージが表示されましたが、動作する唯一の方法は次のとおりです。

mv /var/lib/dpkg/info/package.* /tmp/
dpkg --remove --force-remove-reinstreq package

使用しているだけで

dpkg --remove --force-remove-reinstreq package

パッケージを削除せず、移動するファイルへの正しいパスを表示します：

mv /var/lib/dpkg/info/package.* /tmp/

パッケージをアプリケーション名に置き換えます。 UbuntuでSudoを使用し、Debianのルートになります。

5
DangerFireBob

インターネットでこのコマンドを見つけました。

dpkg --purge --force-depends application

http://www.debian-administration.org/article/Reinstalling_packages_to_fix_problems 。

3
vrcmr

ここで混乱の原因と思われる1つのことを明確にしたかっただけです。 dpkgユーティリティは、パッケージの依存関係を認識または追跡しません。これは、aptが開発された大きな理由です。このページのセクション8.6でそれについて読むことができます Debian GNU/Linux FAQ-Debianパッケージ管理ツール

  • Aptを使用する場合：パッケージAを削除し、パッケージBと呼ばれる依存関係があり、パッケージBに他の依存パッケージがない場合、パッケージAとBは削除されます。パッケージB DIDに他の依存パッケージがある場合、パッケージAのみがパージされます。

  • Dpkgの場合：依存関係は何ですか？あなたは私にいまいましいをパージするように言った
    パッケージ、それが私がしたことです！あなたの側の悪い計画はしません
    私の側で緊急事態を作ります。

とはいえ、ここでは、各パージ方法に使用できる2つのワンライナーを示します。

dpkg --list |grep "^rc" | cut -d " " -f 3 | xargs Sudo dpkg --dry-run --purge

apt-get autoremove -y; apt-get --dry-run purge -y $(dpkg --list |grep '^rc' |awk '{print $2}')

--dry-runを削除して、実行されたアクションを報告する代わりに、実際のパージ操作を実行します。

1
Sysinfo.io

削除するアプリケーションによって異なります。 yesコマンドを発行する前に、必ず依存関係を確認してください。コマンドラインで何かを削除すると、不要になった少数のライブラリが表示されることがあります。これらはapt-get autoremoveで削除できます。

Sudo apt-get remove --purge applicationnameなどのコマンドを使用すると、他のアプリケーションに必要な依存関係が削除され、システムが破損する可能性があることに注意してください。

より安全な方法で実行したい場合は、ソフトウェアセンターまたはapt-get remove applicationnameのみを使用していつでも削除できます。依存関係が不要になった場合は、後でapt-get autoremoveを発行してください。

1
gustavokrm