👨🏽‍🤝‍👨🏻 💂🏼 🙆🏻 make installを使用してはならない理由について、教育プログラムを取り、撮影したい 👨🏽 🚊 🔘

_{このメモを書くために、私は記事へのコメントでこのトピックに関する詳細なコメントを作成するのにうんざりしているという事実に勇気づけられました。特定のディストリビューション用に何かを組み立てて設定するための指示の一部として、make installを提案しています。}

一番下の行は、「make install」または「sudo make install」の形式のこのコマンドは、最新のディストリビューションでは使用できないことです。

しかし、インストールガイドのプログラムの作成者は、このコマンドを使用する必要があると書いています。はい、そうです。しかし、これは彼らがあなたがどのディストリビューションを持っているか知らないことを意味し、それがディストリビューションであるかどうか、あなたは多分あなたはセクトに入り、LFS ~~によって~~ smoke製され、あなたの民族システムの下で彼らの作成をコンパイルすることに決めたということです。また、make installは普遍的ですが、これはしばしば間違った方法です。

叙情的な余談

ご存知のように、通常の操作では、ほとんどのソフトウェアをコンパイルするだけでなく、システムに正しくインストールする必要があります。プログラムは必要なファイルを特定の場所で見つけることを期待し、ほとんどの* nixシステムのこれらの場所はコンパイル段階でコードに接続されます。この側面に加えて、linux / freebsd / WindowsとMacOSのインストールプロセスの主な違いは、プログラムがProgram Filesまたは/ Applicationsの個別のディレクトリにファイルの束を置くだけでなく、ファイルシステム全体に広がることです。ライブラリはlibに、実行可能ファイルはbinに、configsはetcに、すべての種類のデータはvarなどに移動します。突然それを更新する必要がある場合、新しいバージョンを使用すると、古いバージョンの残りのファイルが完全に予測不能な結果につながる可能性があり 、しばしば良くないため、これらすべてを何らかの方法で最初にクリーンアップする必要があります 。このイベントの確率はそれほど高くありませんが、戦闘サーバーで必要ですか？

それで何？

そのため、make installを使用して直接インストールした場合、ほとんどの場合、ソフトウェアをアンインストールまたは更新できません 。さらに、古いバージョンの上に新しいバージョンをインストールすると、構成の変更が消去される可能性があります。 make installは、それが言っていることを正確に実行します-既に何かがあるという事実を無視して、適切な場所にファイルをインストールします。このプロセスの後、何がどこに置かれたのかについての情報はまったくなく、消化可能な形にすることは不可能です。もちろん、Makefileがアンインストールアクションをサポートすることもありますが、これはそれほど一般的ではなく、正しく動作するという事実もそうではありません。さらに、アンパックされたソースコードのツリーとアンインストール用のアセンブリルールを保存することは、どういうわけか奇妙です。

どうやって戦うの？

ディストリビューションにはパッケージを更新する機能がある場合があるため、この問題を解決するためにパッケージマネージャーのようなものを思いつきました。使用する場合、インストールはほぼ次のようになります。

生成されたアーカイブは特定の方法で取得されます
一般にどのバージョンであるか、依存しているもの、競合しているもの、インストール/削除/構成などのスクリプトを実行する必要があるという情報が抽出されます
進行中の直接インストール手順
配信された場所と内容に関するすべてのデータがパッケージマネージャーデータベースに追加されます。

この場合、アップグレード中に余分なものを安全に削除できます。同時に、構成としてマークされたファイルがシステムで変更されたかどうかを確認し、新しいバージョンで内容が異なる場合の対処方法を尋ねます。また、パッケージマネージャーは、別のパッケージをインストールするときに、あるパッケージのファイルを上書きすることを許可しません。一般的に、彼は多くの有用なことを行うことができます。

無知/怠inessから、指示に従ってmake installをコピーして貼り付けると、パッケージマネージャーが知らないファイルがシステムに表示されます 。それが暗示するすべてのことで、前にリストされたものだけでなく。

どうする

もちろん、すべてのインストールが/ opt / mycoolapp /のどこかに行くようにソースツリーを構成し、必要に応じて手動で削除することもできますが、多くの不快なことが出てくる可能性があります。ライブラリをアップロードすると、ローダーはそれらが置かれているディレクトリについて何も知らないため、プログラムの作成者は、たとえば、$ prefix / share / xsessions /にファイルを置くと、ディスプレイマネージャーがそれを取得することを期待できます。 pkgconfigなどのパスは言うまでもありません。

そのため、パッケージを収集する必要があります。

これで***する時間はありません。もう一度インストールする方が良いです。すべてがシンプルで明確です！

落ち着いて彼は私たちの足に縛られています。一見するとすべてが怖くて複雑ではありません。

checkinstall

make installの代わりに起動されるこの素晴らしいユーティリティは、いくつかの質問をします。その後、パッケージ自体を収集してインストールします。すべてを更新するとき、古いゴミのクリーンアップに問題はありません。

debパッケージを手動でビルドする

そのような自動化（これはまだ間違いを起こすことがある）を信頼したくない、またはいくつかの変更を行いたいが、それでも通常のパッケージアセンブリプロセスを処理するのが面倒な場合は、ペンでパッケージを収集できます。 Debianベースのシステム用にビルドする方法を説明します。システムに精通していることが最善だからです。イデオロギー的には正しくありませんが、出力は追加のエンティティを含まない完全に正しいパッケージです。これは次のように行われます。

始めるために、configureまたはautogen.sh用に事前定義されたパラメーター--prefix = / usrおよび--exec-prefix = / usrを使用してソフトウェアを収集します。

次に、一時ディレクトリにインストールします。私たちは書きます：

fakeroot
make install DESTDIR=`pwd`/tempinstall

. , fakeroot-, . . , . fakeroot- , .

« » DEBIAN DEBIAN/conffiles , /etc:

cd tempinstall
mkdir DEBIAN
find etc | sed "s/^/\//" > DEBIAN/conffiles

DEBIAN/control :

Package: _
Version: 1.2.3
Architecture: amd64/i386/armel/all
Maintainer:    ,  ,    ,  dpkg  
Depends:       .
Priority: optional
Description:   - ,

preinst, postinst, prerm postrm.

, dpkg -b tempinstall tempinstall.deb, dpkg -i , .

«» , , .

, , .

: checkinstall make install. .

make installを使用してはならない理由について、教育プログラムを取り、撮影したい