D. J. Bernstein [translated to Japanese by Yusuke Shinyama, 2002-09-06]
UNIX
/package の階層

共有度

Sun が /usr/spool/mail/var/spool/mail に移したとき、 何ダースもの重要なプログラムや、数えきれないほどのユーザスクリプトが 動かなくなりました。 Sun が /usr/man/usr/share/man に移したとき、 何百というインストール用のスクリプトが動かなくなりました。

共有度のバラエティが変わらない場合でも、 ファイルがあるレベルの共有度から別のレベルの共有度に移ることはありえます。 もし共有度の変更が名前を変更するということになれば、 そのファイルへのアクセスは失われます。 以下の 2つの例を見てください。

最終的に Sun は自分のおかした間違いを理解しました。 Sun がカーネルに特化したファイルを作って、 別の共有を導入したときは、 /usr/sbin/adb -> /usr/kvm/adb のようなシンボリックリンクを作って、システムが動かなくなることのないようにしました。

共有度によってアクセスするファイルの名前を決めるという考え方は、間違っています。 共有度は、一定ではないのです。 名前は、一定でなければなりません。

/package はどのようにファイル共有をサポートするのでしょうか? 答え: ファイル共有をしているシステムでは、 パッケージマネージャはそのシステムに特化された設定ファイルと、 パッケージにふくまれるわずかな共有情報を使って、 適切なシンボリックリンクを自動的に用意することができます:

     /package/admin/daemontools-0.76/src
               -> /shared/dist/admin/daemontools-0.76/src
     /package/admin/daemontools-0.76/package
               -> /shared/dist/admin/daemontools-0.76/package
     /package/admin/daemontools-0.76/compile
               -> /shared/syst/openbsd-i386/admin/daemontools-0.76/compile
     /package/admin/daemontools-0.76/command 
               -> /shared/syst/openbsd-i386/admin/daemontools-0.76/command
けれどもこれに注意する必要があるプログラムは、パッケージマネージャだけです。 これらのファイルは共有度を無視してアクセスされます。

ファイル共有をしていないシステムでは、 /shared に悩まされる理由はまったくありません。 愚かなる者たちよ、ものごとは単純にしておきなさい。

パッケージを作るときに、 package/sharing というファイルをつくれば、ファイル共有をサポートすることができます。 これはどのディレクトリがどの共有度レベルであるかを宣言するものです。 たとえば、 /package/admin/daemontools-0.76/package/sharing というファイルはこうなっています:

     command:syst
     compile:syst
     package:dist
     src:dist
現在のところ定義されている共有度レベルは次のとおり: これ以外のレベルも将来定義されるかもしれません。

一定でない共有度の例

これは私が fhs-discuss メーリングリストに送った 2001-01-15 メッセージの抜粋です。
     /etc/passwd でたびたび使われる      #! ラインでしばしば使われる
     ppplogin シェルスクリプトについて   perl 実行可能ファイルについて
     考えてみる。                        考えてみる。

     シェルスクリプトは、Emacs スクリ    実行可能ファイルは、バイナリ
     プトと同じように /usr/share の      ファイルと同じように /usr の
     共有度をもっている。つまり読み込み  共有度をもっている。つまり読み込み
     専用であり、アーキテクチャに依存    専用であり、アーキテクチャに依存
     しない。                            する。

     しかし、もし ppplogin をシェルス    しかし、もし perl が特定の CPU の
     クリプトからコンパイル済のプログ    種類ごとに別々にコンパイルされて
     ラムに変更したらどうなるだろうか?   いたらどうなるだろうか? 突如これは
     突如これはアーキテクチャ依存に      CPU に特化した共有度になるのだ。
     なるのだ。したがって /usr の        これは /usr よりもさらに共有しにく
     共有度をもつことになる。            いものになる。

     もしあなたが、この共有度の変更は    もしあなたが、この共有度の変更は  
     そのファイルにアクセスする名前を  	 そのファイルにアクセスする名前を  
     変えることで実現すべきだと	       	 変えることで実現すべきだと	       
     おろかにも主張するならば、	       	 おろかにも主張するならば、	       
     /etc/passwd における ppplogin の	 #! 行における perl の
     使用は _おかしくなってしまう_。   	 使用は _おかしくなってしまう_。   
     プログラムは動かなくなるのである。	 プログラムは動かなくなるのである。

     どうやってこの問題を解決すべきか?   どうやってこの問題を解決すべきか?   
     ppplogin はシェルスクリプトで       perl は /usr の共有度をもっているので
     あって、それをコンパイルされた      あって、それを特定の種類の CPU ごとに
     プログラムで置き換えることは        コンパイルすることは間違っていると、
     間違っていると、大声で叫ぶべきなの  大声で叫ぶべきなのだろうか?
     だろうか? /etc/passwd に間接参照の  #! 行に間接参照の層を追加して、
     層を追加して、login プログラムが    カーネルがいくつかの場所にある
     いくつかの場所にある ppplogin を    perl を探すようにすべきなのだろうか?
     探すようにすべきなのだろうか?

     もちろんそうではない。単に	         もちろんそうではない。単に	       
     ファイルには一定の名前を与えれば  	 ファイルには一定の名前を与えれば  
     よい。その物理的な場所、とくにその	 よい。その物理的な場所、とくにその
     共有度を変更する必要があるときは  	 共有度を変更する必要があるときは  
     シンボリックリンクを使えばよいの  	 シンボリックリンクを使えばよいの  
     である。しかしある名前でその      	 である。しかしある名前でその      
     ファイルにつねにアクセスできるよう	 ファイルにつねにアクセスできるよう
     保証する必要がある。                保証する必要がある。
     
     ------------------------------------------------------------------------

     どこも論争になるところはありません。一定の決まった名前は誰からも好まれるのです。
     誰もが ppplogin や perl を、それが /usr より共有度が高くても低くても
     /usr からアクセスできるのです。共有の問題はシンボリックリンクによって
     解決します。それ以外の間接参照メカニズムは必要でもありませんし、
     望まれてもいません。

     これで「共有度は一定でない」ことの意味が明らかになったと思います。
     マシン依存のファイルやマシン非依存のファイルには別々の名前空間を
     使うことは --- システムパッケージとサードパーティのパッケージに別々の
     名前空間を使うのと同様に --- 他のプログラムが長期にわたる名前でその
     ファイルにアクセスするのを妨害してしまいます。