web-dev-qa-db-ja.com

プログラムの追跡

単純なプログラムをインストールすると、しばしばmake && make installそしてninstallターゲットもありません。

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

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

software-installationcompilingpackage-management
33
Will03uk

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

詳細には、トップレベルディレクトリ（/usr/local/stowなど）を選択します。各プログラムを/usr/local/stow/PROGRAM_NAMEにインストールします。たとえば、実行可能ファイルが/usr/local/stow/PROGRAM_NAME/binにインストールされ、そのマニュアルページが/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つのプログラムが同じファイルを提供する場合）など。

Rootアクセスを持っていない、または使用したくない場合は、ホームディレクトリの下のディレクトリを選択できます。 ~/software/stow。この場合、PATHに~/software/binを追加します。 manがmanページを自動的に見つけられない場合は、MANPATHに~/software/manを追加してください。 INFOPATHに~/software/infoを追加し、PYTHONPATHに~/software/lib/pythonを追加します。

20
Gilles 'SO- stop being evil'

checkinstall を使用してパッケージ（RPM、Deb、またはSlackware互換パッケージ）を作成できます。これにより、ディストリビューションパッケージマネージャーを使用してアプリケーションを追加/削除できます（ただし、更新はできません）。

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

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

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

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

18
Andrew Lambert

もう1つの代替案は Linux From Scratchヒント からです。

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

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

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

しかし、パッケージ管理は、パッケージユーザーが得意とするすべてのものではありません。パッケージのユーザーにはroot権限がないため、パッケージのインストールは、実行できることが制限されています。たとえば、パッケージユーザーが許可されていないことの1つは、別のパッケージユーザーのファイルを上書きすることです。同じ名前のバイナリ、ライブラリ、またはヘッダーファイルをインストールしようとする異なるパッケージ間の衝突は、あなたが思っているよりも一般的です。パッケージユーザーを使用すると、気付かないうちにパッケージBのインストールがパッケージAのファイルをサイレントに破壊するリスクを負うことは決してありません。パッケージBのインストール中にこれを実行しようとすると、「アクセスが拒否されました」または「操作が許可されていません」というエラーが発生するため、適切な手順を実行できます。パッケージユーザーが許可されていないもう1つのことは、setuidルートバイナリのインストールです。バイナリのsetuidルートを作成する決定も、慎重な管理者がソフトウェアパッケージの作成者に任せたくないものです。

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

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

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

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

LFS：管理しやすく再利用可能なLinuxをゼロから作成

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

3.3グループ

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

chgrpインストール&& chmod g + w、o + t

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

6
user12554

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

私が気付かないかもしれないその点に対して他の誰かがより良い答えをしない限り、手動削除が手動インストールの唯一の方法であると私は言うでしょう。

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