ほとんどのプログラムと同様、oaf も最初は ``local な'' パッケージとして 誕生しました。これは /usr/local/bin/oaf に インストールされており、/usr/local/share/oaf にある ファイルを見るようになっていました。ほかのパッケージは oaf に使ってもらう ファイルを /usr/local/share/oaf に入れていました。
oaf が ``system'' に統合されたとき、 これは /usr/bin/oaf に移動しました。 そしてこれらのもつファイルは /usr/share/oaf に 移されたのです。なぜなら FHS では ``system'' が /usr/local に触れてはいけないことになっているからです。 これで何が起こったかというと、oaf は他のパッケージによって 入れられた /usr/local/share/oaf を見てくれなく なってしまったのでした。
ケーススタディ: aclocal メッセージ: 1.
似たような例です。
ケーススタディ: perl メッセージ: 1 2 3 4 5 6 7 8.
スクリプトは、それが使うインタプリタを指示する行からはじまります。 たとえば #!/bin/sh はカーネルに /bin/sh を使うよう指示します。
この例では、ある人が perl インタプリタを使いたがっていました。 しかし perl の名前は何でしょうか? もし perl が ``system'' の一部ならば、 /usr/bin/perl でいいはずです。 しかしこれはもし perl が ``local'' だと失敗してしまいます。 perl を検索する別のプログラムを起動するのはまずいやり方です。
FHS 信者は、サーチパスの助けをかりてファイルにアクセスすれば ファイルを動かしても問題ないんだと言います。たとえば $PATH, $MANPATH, $LD_LIBRARY_PATH などです。 ユーザはふつう perl が /usr/bin/perl にあるか /usr/local/bin/perl にあるかなど気にしません。たとえば 彼らは $PATH に /usr/bin と /usr/local/bin の両方が あるときでもただ単に perl とタイプします。
この路線で完全なシステムを構築するのに、 理論的な障害はなにもありません。 でもこれはエンジニアリングとしてはひどいしろものです: 細かいところまで全部正しく動かすのには神技的な労力が 必要で、必ずやしっちゃかめっちゃかになってしまうでしょう。
この例では、ある人が ``localな'' mh パッケージを インストールすることで mh をアップグレードさせようとしていました。 不幸にも ``local な'' バージョンの mh は /usr/local/bin に インストールされ、``local な'' インストール手続きは /usr/bin にある 古い ``システムの'' mh には手をつけませんでした。 その結果 mh を起動したユーザは、新しいバージョンのかわりに 望んでいない古いバージョンに当たることになってしまったのです。 なぜなら $PATH には /usr/bin が /usr/local/bin よりも 前にあったからでした。
これも似たような例で、 ある人が ``local な'' BIND パッケージをインストールして BIND をアップグレードしようとしました。 システムはこの新しい /usr/local/bin/named のかわりに 必要のない古い /usr/bin/named を起動していました。
この例では 新しい ``local な'' バージョンの slrn がまだインストールされていない より新しいライブラリに依存していることがわかりました。 そこで管理者は ``system'' バージョンのそれを再インストールしました 不幸にも ``system の'' インストール過程は ``local な'' バージョンの slrn には手をつけなかったので、ユーザは ``system'' 版のかわりに、必要のない ``local な'' バージョンを 使うことになってしまいました。なぜなら $PATH 中で、 /usr/local/bin が /usr/bin よりも前にあったからです。
ケーススタディ: gtk メッセージ: 1.
似たような例です。
ケーススタディ: c++ メッセージ: 1 2 3 4 5 6 7.
これも。
/usr と /usr/local に分けることは、 しばしば名前の衝突をふせぐことになる、と宣伝されています。 /usr/local にある ``local な'' パッケージは /usr にある ``system の'' パッケージと衝突する可能性はないのです。
残念ながら、``local な'' パッケージどうしは互いに衝突する可能性があります。 この例で起こったことは、wuftpd の作者が /usr/local/sbin/xferstats と呼ばれる wuftpd の統計プログラムをつくり、 hylafax の作者が /usr/local/sbin/xferstats と呼ばれる hylafax の統計プログラムをつくったことです。 結果として、wuftpd と hylafax は共存できなくなってしまいました。