Filesystem Hierarchy Standard (FHS) compliancy?

[Bob Kryger]

You know I've read this entire thread (OK, maybe I just skimmed some 
messages) and I am now working on only my second INN installation in some 
10 years, but I am quickly becoming proficient with the software. Oh, I 
only scanned the FHS spec.

I have one primary question:

	What problem with INN would the implementation of FHS solve?

I guess that gives you an idea of where I lean. Now for the points.

1. Personally, I don't consider INN a part of the OS or even a subsystem. 
ifconfig is part of the OS, lpr is a subsystem. Regardless of the size of 
the install INN is an application. A third party application even. 
Therefor, it does not belong integrated with OS tools. It does not provide 
required OS functionality like other ISC software.

2. I have the need to be able to install and run multiple versions of INN 
and related software. By keeping the entire app in a single directory 
structure I am allowed to install multiple versions in /usr/local (I.E. 
/usr/local/news221, /usr/local/news222) and then create a link (I.E. 
/usr/local/news) to the version currently in use. I don't believe that FHS 
would allow this. This may seem arcane or simple to some, but simple is a 
good thing.

3. Last I looked at commercial nix's and software, third party applications 
installed into /opt (or similar) under a directory structure suitable to 
the application.  I.E. 
/opt/SUNWvtas  /opt/HWPopenview  /opt/ORCLxxx.  Heck, FHS even specifies 
this.  http://www.pathname.com/fhs/2.0/fhs-3.8.html

4. That said, I do agree that options are good, and that there may be 
tweaks to the existing file structure. Possibly this might get a low 
priority on "The infamous to-do list." I'd hate to see some of the other 
items take a back seat to FHS implementation.

Regards
Bob