プログラムを追跡する

単純なプログラムをインストールするときmake && make install、アンインストールターゲットを使用することもしばしばあります。

プログラムをアップグレードしたい場合、古いプログラムの上でシームレスに書き換えられると仮定するのは標準プロトコルですか？

これらのプログラムを追跡するにはどうすればよいですか。ほとんどの人は「発火して忘れる」だけで、アンインストールターゲットが指定されていない場合、手動ですべてを削除する必要がありますか？

各プログラムを専用のディレクトリツリーにインストールし、StowまたはXStowを使用して、すべてのプログラムを共通の階層に表示します。Stowは、プログラム固有のディレクトリから共通ツリーへのシンボリックリンクを作成します。

詳細については、トップレベルのディレクトリを選択してください/usr/local/stow。各プログラムをの下にインストールします/usr/local/stow/PROGRAM_NAME。例えば、その実行可能ファイルでインストールされるの手配/usr/local/stow/PROGRAM_NAME/bin、そのmanページ内/usr/local/stow/man/man1のように。プログラムがautoconfを使用する場合は、実行し./configure --prefix /usr/local/stow/PROGRAM_NAMEます。実行した後make install、実行しますstow：

./configure --prefix /usr/local/stow/PROGRAM_NAME
make
sudo make install
cd /usr/local/stow
sudo stow PROGRAM_NAME

これで、次のようなシンボリックリンクが作成されます。

/usr/local/bin/foo -> ../stow/PROGRAM_NAME/bin/foo
/usr/local/man/man1/foo.1 -> ../../stow/PROGRAM_NAME/man/man1/foo.1
/usr/local/lib/foo -> ../stow/PROGRAM_NAME/lib/foo

stowディレクトリの内容を一覧表示することにより、インストールしたプログラムを簡単に追跡できます。また、ファイルはそのプログラムのディレクトリの下の場所へのシンボリックリンクであるため、ファイルがどのプログラムに属しているかを常に把握できます。stow -D PROGRAM_NAMEプログラムのディレクトリを実行してから削除して、プログラムをアンインストールします。実行することにより、プログラムを一時的に使用不可にすることができますstow -D PROGRAM_NAME（実行stow PROGRAM_NAMEして再度使用可能にする）。

同じプログラムの異なるバージョン間をすばやく切り替えたい場合は/usr/local/stow/PROGRAM_NAME-VERSION、プログラムディレクトリとして使用します。バージョン3からバージョン4にアップグレードするには、バージョン4をインストールしてからを実行しstow -D PROGRAM_NAME-3; stow PROGRAM_NAME-4ます。

古いバージョンのStowは、この回答で説明した基本をはるかに超えていません。新しいバージョンとXStow（最近メンテナンスされていない）には、特定のファイルを無視する機能、stowディレクトリ外の既存のシンボリックリンク（などman -> share/man）への対応、競合の自動処理（2つの場合プログラムは同じファイルを提供します）など。

ルートアクセスを使用していない場合、または使用したくない場合は、ホームディレクトリの下にあるディレクトリを選択できます~/software/stow。この場合、に追加~/software/binしますPATH。manマニュアルページが自動的に見つからない場合は、に追加~/software/manしますMANPATH。追加~/software/infoあなたにINFOPATH、~/software/lib/pythonあなたにPYTHONPATH、そしてその適用などに。

あなたが使用できるのcheckinstallをそのように（RPM、デブ、あるいはSlackwareの互換性のあるパッケージ）パッケージを作成するには、アプリケーションを追加/削除するために、あなたのディストリビューションのパッケージマネージャを使用することができます（ただし更新）

コマンドのcheckinstall代わりに使用しmake installます（Debに-Dパラメーターを使用し、-RはRPMで、-SはSlackwareです）：

root@nowhere# ./configure
root@nowhere# make
root@nowhere# checkinstall -D

checkinstallはデフォルトでパッケージをビルドおよびインストールしますが、インストールせずにパッケージのみをビルドすることもできます。

checkinstallは、ほとんどのディストリビューションリポジトリで利用できます。

ほとんどの場合、これがパッケージ、ポート、および他のタイプのマネージャーの背後にあるこのタイプのことを防ぐ理由でした。

手動で削除することは、手動でインストールするための唯一の方法であると言えます。

もう1つの選択肢は、Linux From Scratchヒントからです。

パッケージユーザーを使用した詳細な制御とパッケージ管理

3パッケージユーザー
3.1はじめに

このスキームの基本的な考え方は簡単に説明できます。すべてのパッケージは、特定の「パッケージユーザー」に属します。パッケージをインストールすると、このパッケージユーザーとしてパッケージがビルドおよびインストールされ、インストールされたすべてのファイルがパッケージユーザーによって所有されます。結果として、通常のパッケージ管理タスクはすべて、標準のコマンドラインユーティリティを使用して快適に達成できます。単純なls -l <file>例では、たとえば、どのパッケージに<file>属しているかがわかります。 find -user ...コマンドを使用すると、特定のパッケージに属するすべてのファイルに対して操作を実行できます。たとえば、ファイルを削除してパッケージをアンインストールします。

ただし、パッケージ管理は、パッケージユーザーが満足できるものではありません。パッケージユーザーにはルート権限がないため、パッケージのインストールは実行できる機能に制限があります。たとえば、パッケージユーザーに許可されていないことの1つは、別のパッケージユーザーからのファイルを上書きすることです。同じ名前のバイナリ、ライブラリ、またはヘッダーファイルをインストールしようとする異なるパッケージ間の衝突は、想像以上に一般的です。パッケージユーザーを使用すると、パッケージBのインストールがパッケージAのファイルを気付かずに静かに破壊する危険を冒すことはありません。パッケージBのインストール中にこれを実行しようとすると、「Permission denied」または「Operation not allowed」エラーが発生するため、適切な手順を実行できます。パッケージユーザーに許可されていないもう1つのことは、setuid rootバイナリをインストールすることです。バイナリsetuidルートを作成する決定も、慎重な管理者がソフトウェアパッケージの作成者に任せたくないことです。

通常、パッケージユーザーアカウントには有効なパスワードがないため、ルートのみsu がパッケージユーザーにアクセスできます。これにより、パッケージユーザーがシステムに別の方法でアクセスしてセキュリティを損なうことがなくなります。しかし、あなたはありますが、実際のrootアカウントへのアクセスを持たずにそうするように、特定のソフトウェアパッケージをインストールし、維持することができるようにしたいの共同管理を可能にするために、とにかく、パスワードを設定します。この共同管理者は、たとえば、自分のワークグループに必要な追加のライブラリをインストール、削除、変更できます。ただし、libcなど、自分に属していないライブラリを削除または変更することはできません。

この最初の粗雑な提案の後、私は進化したバリアントを見つけました。

crablfs-ユーザーベースのパッケージ管理システム

これcrablfsは、パッケージ管理に一意のuidとgidを使用したパッケージ管理の最新のサンプルですが、sourceforgeではulfsで再び進化しています。

uLFS：ゼロから管理および再利用可能なLinux

インストールされたパッケージの因果関係のあるユーザーにとっては、「パッケージユーザー」LFSソリューションは軽量で、侵襲性が低く、エレガントだと思います。つまり、パッケージを/usr/localまたはにインストールし/home/user/local、各パッケージの一意のuidとgidsを使用してファイルを追跡しますが、すべてのファイルを従来の場所、共通ディレクトリ/usr/local/binに配置し/usr/local/libます。 more_control_and_pkg_man.txtのMatthias S. Benkmannが説明するきちんとしたLinuxのトリックによって回避されます。これは、通常のファイルとディレクトリのアクセス許可操作のみを必要とします。

3.3グループ

すべてのパッケージユーザーは、少なくとも2つのグループに属します。これらのグループの1つは「インストール」グループで、すべてのパッケージユーザー（およびパッケージユーザーのみ）が属します。パッケージがインストールを許可されているすべてのディレクトリは、インストールグループに属します。これには、/ binや/ usr / binなどのディレクトリが含まれますが、/ rootや/などのディレクトリは含まれません。インストールグループが所有するディレクトリは、常にグループ書き込み可能です。これはパッケージ管理の側面には十分ですが、追加の準備がなければ、すべてのパッケージが異なるパッケージのファイルを置き換えることができるため、追加のセキュリティや制御が得られません（変更はls -l、しかし）。このため、すべてのインストールディレクトリはスティッキー属性を取得します。これにより、ユーザーは新しいファイルを作成し、ディレクトリ内の自分のファイルを削除または変更できますが、他のユーザーのファイルは変更または削除できません。このヒントの残りの部分では、「インストールディレクトリ」という用語が使用される場合は常に、グループインストールに属し、グループ書き込み可能でスティッキーなディレクトリを指します。IOW、<dir>あなたがするインストールディレクトリに変えるには

chgrp install && chmod g + w、o + t

私にとっては、シンプルで賢い解決策のように見えます！私は自分のLFSビルドでこのスキームを使用しましたが、それは実用的なソリューションです...

1. 空のRPMをリマインダーとして作成できます。
2. ソフトウェアを適切にRPMにラップする方法を検討できます。
3. tarインストールのファイルのコピーを残して、/usr/src/non-rpms思い出させることができます（これは私が通常行うことです）。