Gitから手動で複製したパッケージを削除する方法

Gitから手動で複製したパッケージを削除する方法

私のコンピュータからtmuxを削除したいです。私のtmuxバージョンは次のとおりです。

tmux next-3.4

そしてwhich tmux私に以下を与えます:

/usr/local/bin/tmux

以下を使って削除しようとしていますsudo yum remove tmux

Updating Subscription Management repositories.
No match for argument: tmux
No packages marked for removal.
Dependencies resolved.
Nothing to do.
Complete!

私のコンピュータ情報は次のとおりです。

NAME="Red Hat Enterprise Linux"
VERSION="8.6 (Ootpa)"
ID="rhel"
ID_LIKE="fedora"
VERSION_ID="8.6"
PLATFORM_ID="platform:el8"
PRETTY_NAME="Red Hat Enterprise Linux 8.6 (Ootpa)"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:redhat:enterprise_linux:8::baseos"
HOME_URL="https://www.redhat.com/"
DOCUMENTATION_URL="https://access.redhat.com/documentation/red_hat_enterprise_linux/8/"
BUG_REPORT_URL="https://bugzilla.redhat.com/"

REDHAT_BUGZILLA_PRODUCT="Red Hat Enterprise Linux 8"
REDHAT_BUGZILLA_PRODUCT_VERSION=8.6
REDHAT_SUPPORT_PRODUCT="Red Hat Enterprise Linux"
REDHAT_SUPPORT_PRODUCT_VERSION="8.6"
Red Hat Enterprise Linux release 8.6 (Ootpa)
Red Hat Enterprise Linux release 8.6 (Ootpa)

ベストアンサー1

私はtmuxパッケージをインストールせず、tmuxを直接コンパイルしてインストールしました。したがって、パッケージ管理ツール(例yum:)は、ユーザーが直接インストールしたtmuxのバージョンについては何も知りません。

つまり、手動でインストールした場合は、手動で削除する必要があります。

これをより簡単にするためのいくつかの可能性は次のとおりです。

  • 一部のプログラムinstallにはMakefileとターゲットの両方があります。これがうまくいくかどうかはuninstallわかりませんが、tmux確認してみる価値があります。 tmuxのMakefileを実行make uninstallまたは確認して、このターゲットが存在することを確認してください。 makefileターゲットはuninstall常に信頼できるわけではなく、asbuildまたはターゲットに近い場所ではinstallテストされないことがよくあります。警告事項YMMV。頑張ってください!

  • make -n installインストールするすべてのファイルを実行して記録します。その後、手動で削除します。ヒント:.の出力をファイルにリダイレクトすると、make -n特に出力が多い場合に役立ちます。

    ところで、わからない場合は、makeオプション-nは次の実行をテストすることですman make

    -n、、、、--just-print--dry-run--recon

    実行するコマンドを印刷しますが、実行しません(特定の状況を除く)。


未来のための提供:

パッケージングソフトウェアを使用するか、次のプログラムを使用します。GNUストーまたはインストールの確認ソフトウェアをコンパイルしてインストールするとき。パッケージの便利な機能の一部(すべてではない)を提供し、独自のコンパイルされたソフトウェアをより簡単にアップグレードおよび/または削除できるようにします。

99%以上の場合、ソフトウェアを直接コンパイルしても利点はほとんどまたはまったくありません。 「より明るくて新しく」、「バージョン番号が大きい」という言葉には十分な理由はほとんどありません。特に、自己コンパイルされたプログラムを削除する方法や、パッケージソフトウェアと自己コンパイルされたソフトウェアの違いがわからない場合は、さらにそうです。

必要な特定の新機能や影響を与えるバグがあり、最新のアップストリームバージョンで修正されていることがわかり、パッケージの更新を数日または数週間待つことができない場合可能問題を引き起こす価値がありますが...一般的にそうではありません。ただ1つの問題(バグまたは機能不足)を他の問題(パッケージされていないソフトウェア)と交換するだけです。ほぼ常に待つ方が良いです。

あるいは、単にソースコードをダウンロードして実行するのではなく、ディストリビューションmake installのパッケージングシステムを十分に理解して、最新バージョンのパッケージを独自のバージョンで構築することもできます。通常、これはダウンロードのように実行できます。パックソースファイルをダウンロードし、ここにアップストリームパッチを適用してからパッケージを再構築するか、パッケージの変更(debian/ubuntu/etcのdebian/ディレクトリ、RPMベースのディストリビューションの仕様ファイルなど)を最新のアップストリームソースに移植します。

おすすめ記事