/package も同じことをやります。 そして、より信頼できるやり方でやります。 実際には、ソフトウエアやユーザは FHS では 信頼してファイルにアクセスすることができませんが、 /package ならできます。
たとえば: lynx の設定ファイルは /etc/lynx.cfg でしょうか、 それとも /usr/local/etc/lynx.cfg でしょうか? この答えは、lynx が ``system の'' パッケージか、あるいは ``local な'' パッケージかによって違ってしまいます。
反対に、 /package では ``local な'' パッケージが ``system に'' 統合されても 名前は変わりません。
別の例として: hylafax パッケージに含まれている統計プログラムは xferstats と呼ばれているでしょうか、 あるいは xferstat、それとも xferfaxstats? FHS のもとでは、ソフトウエアもユーザもその答えをいうことはできません。 オリジナルの xferstats という名前は wu-ftpd パッケージの 異なる統計プログラムによって使われているからです。 ある OS ディストリビュータは、この名前を xferstat に 変えることで衝突を回避しました。別の OS ディストリビュータは xferfaxstats に変えることで衝突を回避しました。
反対に、 /package における名前はグローバルに割り当てられます。 なので最初から衝突は起こりません。 これは /package の重要な特徴のひとつです。
以下は私の皮肉に満ちた回答です:
ええ、それはたいへん重要な原則ですね!
たとえば csh を例にとってみましょう。これは /etc/csh.cshrc と /dev/log と
/bin/sh とその他多くのファイルを使用します。これらが変更できるように、
これらのファイル名はすべて /etc/csh.conf に記されています。
さて、ある人が /etc/csh.conf それ自身を移動させたいとしましょう。
このため、csh は /etc/csh.conf をさがすのに、ハッシュされた /etc/registry.db
ファイルを使います。
もちろん、いくつかのマシンでは、/etc/registry.db を移動させる
必要があります。だからレジストリのファイル名が COMPILEDFREGISTRY 環境変数に
入っているというわけです。
COMPILEDFREGISTRY 環境変数が別のところで使われていて、
これが衝突するという可能性もまだあります。だからこの変数の名前は
/etc/fregistry_variable_name.txt に入っています。
/etc/fregistry_variable_name.txt を移したいって? おバカさん!
私たちはすでに何十億ものプログラムの main() 先頭で /etc/fregistry_variable_name.txt を
読むようにさせてるんですよ。これ _以外_ ならあきらかに変更可能です。
でも /etc/fregistry_variable_name.txt だけはどこへも移動させてはいけません。