FHSの代替手段は何ですか？

私は15年以上Linuxユーザーです。しかし、情熱を持って嫌いなことの1つは、必須のディレクトリ構造です。私はそれが好きではない/usr/binでバイナリまたはLIBSのためのゴミ捨て場で/usr/lib、/usr/lib32、/usr/libx32、/lib、/lib32等...ランダムなものを中/usr/shareなどそれのダムと混乱します。しかし、それが好きな人や味が違う人もいます。

各パッケージが分離されたディレクトリ構造が必要です。代わりに、メディアプレーヤーのドラゴンが独自の構造を持っている場合を想像してください。

/software/dragon
/software/dragon/bin/x86/dragon
/software/dragon/doc/README
/software/dragon/doc/copyright
/software/dragon/lib/x86/libdragon.so

または：

/software/zlib/include/zlib.h
/software/zlib/lib/1.2.8/x86/libz.so
/software/zlib/lib/1.2.8/x64/libz.so
/software/zlib/doc/examples/...
/software/zlib/man/...

あなたはポイントを得る。私のオプションは何ですか？私のスキームのようなものを使用するLinuxディストリビューションはありますか？一部のディストリビューションを変更して（Gentoo ??）のように動作させることはできますか、それともLFSが必要ですか？この分野に先行技術はありますか？スキームが実行可能か実行不可能かについての出版物が好きですか？

OS Xを探していません。:)しかし、OS Xに触発されたものはまったく問題ありません。

編集：どのようにPATH、LD_LIBRARY_PATHそして小さなパスのセットに依存する他の環境変数がうまくいくかわからない。KDEエディターのKateをインストールしておけば/software/kate/bin/x86/bin/kate、バイナリーへのフルパスを入力して起動するのは問題ないと思います。動的ライブラリとdlopen呼び出しに対してどのように機能するか、私にはわかりませんが、解決できないエンジニアリングの問題になることはありません。

最初に、利益相反の免責条項：私は長年GoboLinux開発者です。

第二に、ドメインの専門知識の先行請求：私は長年GoboLinux開発者です。

現在使用されている構造はいくつかあります。GoboLinuxには1つがあり、GNU StowやHomebrewなどのツールは非常によく似たものを使用します（主にユーザープログラム用）。NixOSは、プログラムおよび生活哲学に非標準の階層も使用します。これは、かなり一般的なLFS実験でもあります。

これらのすべてを説明し、それが実際にどのように機能するかについての経験からコメントします（「実現可能性」）。簡単な答えは、はい、それは実行可能ですが、本当にそれを望んでいるということです。

GoboLinux

GoboLinuxの構造は、説明したものと非常によく似ています。ソフトウェアは、下にインストールされて/Programs：/Programs/ZSH/5.0.8通常では、ZSH 5.0.8に属するすべてのファイルが含まれていますbin/ lib/ ...ディレクトリ。システムツールは、/System/Links階層にあるこれらのファイルへのシンボリックリンクを作成し、/usr¹にマッピングします。PATH変数は、単一の統合された実行ファイルのディレクトリが含まれており、LD_LIBRARY_PATH未使用です。ソフトウェアの複数のバージョンが同時に共存できますが、一度にbin/zshアクティブにリンクされるのは、特定の名前（）の1つのファイルのみです。他のユーザーはフルパスでアクセスできます。

互換性のあるシンボリックリンクのセットも存在するため、統合された実行可能ファイルのディレクトリ/binなどに/usr/binマップされます。これにより、実行時にソフトウェアの作業が楽になります。カーネルパッチGoboHideを使用すると、これらの互換性のあるシンボリックリンクをファイルリストから隠すことができます（ただし、トラバーサルは可能です）。

コントラ別の答え、あなたはしていないカーネルのコードを変更する必要があります。GoboHideは、純粋に化粧品であり、カーネルはgeneral²でユーザ空間のパスに依存しません。GoboLinuxには、特注のinitシステムがありますが、これを行うために必須ではありません。

キャッチフレーズは常に「ファイルシステムがパッケージマネージャー」でしたが、システムにはかなり普通のパッケージ管理ツールがあります。あなたは使用してすべてを行うことができcp、rmおよびln、しかし。

GoboLinuxを使用する場合は、大歓迎です。ただし、小規模な開発チームであり、以前に使用したい人がいなければ、必要なソフトウェアがパッケージ化されていないことに気付くでしょう。幸いなことに、システム用のプログラムを作成するのは一般にかなり簡単です（標準の「レシピ」は約3行の長さです）。悪いニュースは、不快なほど複雑な場合があることです。これについては、以下で詳しく説明します。

刊行物

いくつかの「出版物」があります。私はでプレゼンテーションを行いましたlinux.conf.au 2010ビデオで利用可能で、一般的に全体そのカバーのすべて、などのシステム上：OGV 、MP4（また、あなたの地元のLinuxオーストラリアミラー上）。私もメモを散文に書きました。GoboLinuxのWebサイトには、いくつかの異論や問題に対処する有名な「私は無知ではありません」など、いくつかの古いドキュメントもあります。最近、私たちは少しばかりガンホーになっていると思いますし、将来のリリースではシンボリックリンクのベースロケーションとして採用されると思います。/usr

NixOS

NixOSは、インストールされた各プログラムをの下の独自のディレクトリに配置し/nix/storeます。これらのディレクトリには、次のような名前が付けられ/nix/store/5rnfzla9kcx4mj5zdc7nlnv8na1najvg-firefox-3.5.4/ています。そのプログラムにつながる依存関係と構成のセット全体を表す暗号化ハッシュがあります。そのディレクトリ内には、関連付けられたすべてのファイルがあり、ローカルのほぼ通常の場所にあります。

また、一度に複数のバージョンを使用して、それらのいずれかを使用することもできます。NixOSには、再現可能な設定という哲学があります。基本的に、最初から設定管理システムが組み込まれています。インストールされたプログラムの正しい世界をユーザーに提示するために、何らかの環境操作に依存しています。

LFS

Linux From Scratchを使用して、必要な階層を正確にセットアップするのはかなり簡単です。ディレクトリを作成し、適切な場所にインストールするようにすべてを構成するだけです。GoboLinuxの実験を構築する際に何度かやってみましたが、それは単純なLFSよりもそれほど難しくありません。その場合、互換性シンボリックリンクを作成する必要があります。それ以外の場合はかなり難しくなりますが、ユニオンマウントを慎重に使用すると、本当に必要な場合はおそらく回避できます。

ある時点でそれについてのLFSヒントがあったように感じますが、今は見つけることができません。

実現可能性について

FHSについてのことは、それが標準であり、非常に一般的であり、書かれた時点での既存の使用法を広く反映しているということです。ほとんどのユーザーは、本質的にそのレイアウトに従わないシステムを使用することはありません。その結果、多くのソフトウェアには潜在的な依存関係があり、誰も気付かないこともあります。

これらのスクリプトはすべて#!/bin/bash？そこにBashがないとダメです。GoboLinuxにこれらすべての互換性シンボリックリンクがあるのはそのためです。実用的です。多くのソフトウェアは、ビルド時または非標準レイアウトでの実行時に機能しなくなり、修正するためにパッチを必要とします。

通常、基本的なAutoconfプログラムは、ユーザーが指定した場所に自動的にインストールします--prefix。正しいを渡すプロセスを自動化するのはかなり簡単です。他のビルドシステムは、意図的に階層をベイク処理したり、作成者が移植性のない構成を記述したりすることで、必ずしも優れているとは限りません。CMakeは、後者のカテゴリの主要な犯罪者です。つまり、この世界に住みたいのであれば、他の人のビルドシステムで多くの面倒な作業を事前に準備する必要があります。コンパイル中に生成されたファイルに動的にパッチを適用するのは本当に面倒です。

ランタイムはまた別の問題です。多くのプログラムは、自分のファイルまたは他の人のファイルがどこにあるのか、それらに関連するのか、絶対に見つかるのかについての仮定を持っています。一貫性のあるビューを表示するためにシンボリックリンクを使用し始めると、多くのプログラムがそれらを処理するバグを抱えています（または、おそらく、あなたにとって役に立たない間違いなく正しい動作）。たとえば、ツールfoobarは、そのbaz隣またはで実行可能ファイルを見つけることを期待する場合があり../sbinます。シンボリックリンクを読み取るかどうかに応じて、それらは2つの異なる場所になる可能性があり、どちらも正しいとは限りません。

組み合わされた問題は/usr/shareディレクトリです。もちろん、共有ファイル用ですが、すべてのプログラムを独自のプレフィックスに入れると、実際には共有されなくなります。それは、標準のアイコンなどを見つけることができないプログラムにつながります。GoboLinuxはこれをかなりい方法で処理しました。ビルド時に$prefix/shareは、へのシンボリックリンク$prefix/Sharedであり、ビルド後にはリンクがグローバルshareディレクトリを指していました。コンパイル時のサンドボックスとファイルの移動を使用してshare（および他のディレクトリ）を処理するようになりましたが、リンクの読み取りによる実行時エラーが問題になる可能性があります。

複数のプログラムのスイートは別の問題です。GoboLinuxがGNOMEを完全に機能させることは一度もありません。また、レイアウトの相互依存性が非常にベーキングされているため、すべてを修復するのは手に負えないため、NixOSも機能するとは考えていません。

そう、はい、それは実行可能ですが、：

• 物事を機能させるだけでは、かなりの作業が必要になります。
• 一部のソフトウェアは動作しない可能性があります。
• 人々はあなたを面白く見ます。

これらはすべて問題になる場合もあれば、そうでない場合もあります。

¹バージョン14.01は/System/Index、に直接マッピングします/usr。将来のバージョンではリンク/インデックス階層が削除され、/usr全面的に使用される可能性があります。

² /bin/shデフォルトで存在する必要があります。

両方GoboLinux（F.sbが言及）とguix GNUバイナリの「現在」のバージョンを指すようにシンボリックリンクと一緒にパッケージごとのディレクトリ構造を使用する分布です。

安定したシステムが必要な場合は、GoboLinuxが最適です。GNU guixは、まだ生産準備が整っていないことを明示しています。GoboLinuxは何年も前から存在しています。私も自分で試したことはありません。

GoboLinuxを確認してください。

ディレクトリ構造を変更する場合は、カーネルコード、ブートプロセス、rcファイルに基づくディレクトリランレベル、およびパッケージマネージャーを変更してから、ディレクトリ構造を変更する必要があります。

Linux FHSは、1980年代後半にSunや他のUNIX企業が決定したものに基づいています。

当時の重要な変更は、放棄/usr/local/して/opt// { bin！lib！man！...}

今日/ usr / binがゴミ捨て場として使用されている理由を探しているなら、GNOMEは最も責任あるプロジェクトの1つだと思います。

32ビットライブラリと64ビットライブラリで起こったことは、FHSが原因であるようです。

Solarisは/lib /usr/binおよびでプラットフォーム固有のサブディレクトリを導入しました/usr/lib。1988年からサンが基本概念をどのように強化したかをご希望ですか。

すべてのパッケージは、ファイルシステムの独自の部分を持っていた場合、あなたは非常に大きいと扱いにくい環境変数必要があるだろうPATH、LD_LIBRARY_PATHと類似しました。

もちろん、この方法でパッケージを自分でインストールしてから、GNUモジュールのようなものを使用して、環境にあるかどうかを管理することができます。システムソフトウェア。