掘るか、掘らないか？
一見シンプルに見えますが、OSの重要な部分、つまりファイル割り当てのルールや構造、またはもっと単純に-順序と利便性について話したいです。 UNIXライクなOS、特にLinuxカーネルに基づいたさまざまなディストリビューションに触れます。
そのため、プログラマーはプログラムを作成し、それを配布したいと考えています。今では、ユーザーがプログラムをインストールするというタスクがあります。 このために、標準（FHS、LSB）があるように見えますが、ソフトウェアインストールツールの種類は単純であるため、プログラマーは、できる限り、単純なREADMEからより複雑なものまで、インストールツールを実装しています。
はい。今日、ほとんどのディストリビューションにはプログラムをインストールするためのシステムがあり、ディストリビューションキット内でプログラムのインストールに関する問題を解決し、プログラマーの作業をある程度容易にします。 そして、異なるディストリビューション（データセンターのラック、VM）の大規模なグループを管理する必要がある場合、さまざまな構成管理システム（CFEngine、Bcfg2 puppet、Chefなど）が作成されました。 そして、すべては大丈夫のようですが、過去14年間（RedHat Linux 5.2がピッキングを開始した瞬間から）の松葉杖、この多様性の感覚は私を残していません...それで問題は何ですか？
ルーツ
典型的なLinuxディストリビューションのプログラムをインストール/アンインストールするために今日使用されているすべての表面的なものを削除しようとします-helloworldよりも難しいプログラムをどう処理するかを削除します：
- 構成管理システム。
- パッケージマネージャー;
- 例外なく、すべてのインストールスクリプト。ライブラリ、リソース、プログラムドキュメント、コンパイルスクリプトなどを配置するためのディレクトリの作成などの予備的なアクションを実行するスクリプトを含みます。
- README / INSTALLファイルも。
プログラムとそのすべてのコンポーネントをインストールしてからアンインストールするために、現在実行する必要があるアクションは何ですか？
プログラムの一部の場所を見つけ、必要なディレクトリを作成し、ファイルをコピーし、環境を更新すると、プログラムが正常に実行されるようになったとします。
しかし、時間が経ち、プログラムのコンポーネントがどこにどのように配置されているかを長い間忘れていました。プログラムの名前を覚えているだけで、それによって作成されたすべてのコンポーネントとファイルとともに削除する必要があります。 そして、ここで私は停止しています-何をすべきか？ プログラムstraceとlddを設定しますか？ 同じ名前のすべてのディレクトリを見つけてドキュメントを削除しますか？ プログラムとそのすべてのコンポーネントを削除するだけですか？ そして、すべてが見つかって削除されるという事実ではありません。
だから、もしあなたがre敬の念を抱かずにやるなら、Linux上でプログラムをインストール/アンインストールする際に観察される状況は、よく隠された
そして、それについてどうすればいいですか？
必要な属性をコピーしてコピーするファイルに設定できる簡単なインストールプログラムがありますが、その作業の結果は通常のrmで削除する必要があります。
プログラムを起動して実行を完了するには、 execve（）および_exit（）関数を使用できます。ファイルを開いて閉じるには、 open（） / create（）およびclose（）関数があります。 同時に、プログラムの実行/停止にはプロセス識別子 （ PID ）があり、ファイルのオープン/クローズにはファイル記述子があります。 したがって、 プログラムをインストール/アンインストールするためのプログラム配置識別子のようなものをインストールしないのはなぜですか？それはデプロイID（ DID ）/インストールID（ IID ）であり、実際には標準のUUIDであり、タイプ_appinstall（） / _appupdate（） / _appuninstall（） /などのこの識別子と、タイプpsの対応するコマンド、たとえばapp？ そして、そのコンポーネントでプログラムをホストしないのはなぜですか？
/etc/program.conf /etc/program.conf.d/someone.conf /usr/bin/program /usr/lib/program/libprogram.so /usr/share/doc/program/manual.txt /var/program/database
そして
/etc/<did>/program.conf /etc/<did>/program.conf.d/someone.conf /usr/bin/<did>/program /usr/lib/<did>/libprogram.so /usr/docs/<did>/manual.txt /var/<did>/database
はい、別のパッケージマネージャーになります。便利なGUIが表示され、構成管理システムはどこにも行きません。 しかし！ すべてがPOSIXに分類され、プログラムとそのコンポーネントの配置が厳密に行われ、識別子データベースが破壊された場合でも削除が簡単になります。 さらに、ファイルの割り当て構造をたどって、データベースを再作成することで、locatebのインデックスを作成するupdatedbと同じように、すべての識別子を復元できます。 非常に簡単に、1つのプログラムの複数のバージョンまたはインスタンスをインストールし、バージョンを切り替えることが可能になります。
さらに進んだ場合、プログラム構成ファイルをいくつかの共通点に持ち込み、たとえば同じxmlまたはjsonを使用してコンテンツを統合しますが、事前定義されたものに準拠するように構成を検証する_appconfigdeploy（）の方法で機能を提供しますPOSIX回路。
クラッカーを乾かすか、釣り竿を投げますか？
一般に、 GoboLinux （開発を停止しているようです）など、コンポーネントと構成ファイルのプログラムの配置を統一する方向に動いていると思われるディストリビューションがあり、私の考えでは、このアプローチに最も近いのは、 nixパッケージマネージャーとそのベースで作成されたNixOSディストリビューションです。 しかし、FHSと同じ大規模なイニシアチブ、議論が必要だと思います。 もちろん、そうでない限り。
これらはパイです。
PSどういうわけか私は、gentoo.ruフォーラムで2006年にこのトピックに関する議論を提起しました。
UPD ：すぐにマイナス、質問をします：
プログラマーは、たとえば、プロセスの分岐方法の違いの出現、たとえばdebianとredhatに適しているでしょうか？ 私はそうは思わない（プラットフォームに留意）。 では、なぜ松葉杖は、プログラムをインストールするためのさまざまなルールやアプローチの形をしているのでしょうか？
UPD ：LORのコメントからわかるように、ステレオタイプに対処できないことは、ハードプレスのWindowsユーザーに限ったことではありません。
スキームは単純なロジックによって区別されます-すでに確立され標準化されたベースファイル階層を破壊せずにシステムにデプロイされた1つのパッケージインスタンスの1つのID（変更が過度に合計されているnixosとは異なり、/ usr / contains / usr / bin / env-> / nix / store / id-coreutils-version / bin / env、これはpm nix自体によって、メインシステムにまったく影響を与えることなく、$ HOMEを使用して任意のディストリビューションでゴミ箱を整理できるという事実にもかかわらず）。
実際に取得されたIDは、プログラムのすべての部分の識別子として機能し、ファイルコンポーネントに1つだけレベルを追加して、プログラムコンポーネントを互いに（重要ではないが、いくつかのバージョンの同じプログラムを含む）分離します。このIDを使用して簡単に制御できます。プログラムおよびそのコンポーネントへのアクセス権。
もちろん、彼らが受け入れない主なものは人間が読めるパス （hrp）です-KISSがhrpに見られて困惑しているという事実による誤解-なぜ突然プログラムとそのコンポーネントへのパスが何かになるのか複雑ですが、複雑なことは何もありません。fstabを見てください。なぜマウントにラベルとuuidを使い始めたのですか？ はい、私は便利が欲しかったからです。 だから、少なくとも私は自分のアメニティを手に入れようとしました。
- カブの有無に関係なく、プログラムのより良い制御;
- cプレフィックスとスロットを気にせずにプログラムのいくつかのバージョンを維持できます。
- プログラムの名前を使用してプログラムの一部にアクセスできるようにする（gsmモジュールの初期化コマンドとダイヤラーコマンドを毎回configに書き込むことなく、スマートダイヤラーから呼び出す関数をプルすることで行うように）、シェルレベルで、さまざまなツール、エイリアスの作成、環境変数の編集。