oaf, like most programs, started life as a ``local'' package. It was installed in /usr/local/bin/oaf and looked for files in /usr/local/share/oaf. Other packages put files into /usr/local/share/oaf for oaf to use.
When oaf was integrated into ``the system,'' it was moved to /usr/bin/oaf, and its files moved to /usr/share/oaf, because FHS doesn't let ``the system'' touch /usr/local. What happened in this case is that oaf didn't find files that were put into /usr/local/share/oaf by another package.
Case study: aclocal. Messages: 1.
Similar case.
Case study: perl. Messages: 1 2 3 4 5 6 7 8.
A script begins with a line naming the interpreter used for the script. For example, #!/bin/sh tells the kernel to use /bin/sh.
What happened in this case is that someone wanted to use the perl interpreter. But what is perl's name? /usr/bin/perl works if perl is part of ``the system,'' but it fails if perl is ``local.'' The clumsy workaround is to invoke another program that searches for perl.
FHS advocates say that it's just fine to move files if the files are accessed with the help of search paths: $PATH, $MANPATH, $LD_LIBRARY_PATH, etc. Users don't normally worry whether perl is in /usr/bin/perl or /usr/local/bin/perl, for example: they simply type perl, with both /usr/bin and /usr/local/bin in $PATH.
There's no theoretical obstacle to building a complete system along these lines. But it's bad engineering: getting all the details right is a royal pain, and people inevitably screw it up.
What happened in this case is that someone tried to upgrade mh by installing a ``local'' mh package. Unfortunately, the ``local'' version of mh was installed in /usr/local/bin, and the ``local'' installation process didn't touch the old ``system'' version of mh in /usr/bin. Users who invoked mh ended up with the undesirable old version instead of the new one, because /usr/bin was before /usr/local/bin in $PATH.
Case study: named. Messages: 1 2.
In this similar case, someone tried to upgrade BIND by installing a ``local'' BIND package. The system invoked the undesirable old /usr/bin/named instead of the new /usr/local/bin/named.
Case study: slrn. Messages: 1 2 3.
In this case, a new ``local'' version of slrn turned out to rely on newer libraries that weren't installed, so the administrator reinstalled the ``system'' version. Unfortunately, the ``system'' installation process didn't touch the ``local'' version of slrn. The user ended up with the undesirable ``local'' version instead of the ``system'' one, because /usr/local/bin was before /usr/bin in $PATH.
Case study: gtk. Messages: 1.
Similar case.
Case study: c++. Messages: 1 2 3 4 5 6 7.
Similar case.
The split between /usr and /usr/local is often advertised as preventing name conflicts. ``Local'' packages in /usr/local can't bump into ``system'' packages in /usr.
Unfortunately, ``local'' packages can bump into each other. What happened in this case is that the wuftpd authors wrote a wuftpd statistics program called /usr/local/sbin/xferstats, and the hylafax authors wrote a hylafax statistics program called /usr/local/sbin/xferstats. Consequently wuftpd and hylafax were unable to coexist.