Filesystem Hierarchy Standard patch

bill davidsen davidsen at tmr.com
Mon Apr 9 19:39:07 UTC 2001


In article <Pine.LNX.4.30.0104070528300.5251-100000 at shieldbreaker.rem.cmu.edu>,
James Ralston  <qralston+ml.inn-workers at andrew.cmu.edu> wrote:
| 
| On Sat, 7 Apr 2001, Marco d'Itri wrote:

| > Since I remember using INN on linux, distributions installed inn
| > files in /{etc,var,lib,spool}/news, which are perfectly good names.
| > I wonder why you propose to break current systems and traditional
| > paths.
| 
| Whether certain subdirectories are called "inn" or "news" is arbitrary
| to a certain degree.  Also, the location of the subdirectory itself
| matters.  In /usr/lib, subdirectory names are usually chosen based on
| the name of the package, not on the type of service or service name.
| But in, say, /var/log, or /var/run, subdirectories are usually named
| after the type of service or service name.

  At this point, let me say that I strongly favor the implementation
name (inn) or the service name (news), since it's less likely to
conflict on test machines with several flavors of nntp servers
installed, and on machines running some flavor of wire service type
news.

| I thought that /etc/inn was a more appropriate FHS default than
| /etc/news; similarly for /usr/lib/inn versus /usr/lib/news.  However,
| I'm flexible on that; if the consensus here is that it would be better
| to use "news" for subdirectory names everywhere, we can change the
| defaults accordingly.  We could also go ask the FHS list for
| advice--it might distract them from their (seemingly endless)
| discussion of where mount points for removable media should be placed.
| ;)

  All my above being said, I will continue to keep application stuff in
/usr/local, to preserve my sanity and ease of backing up stuff which
makes the machine one thing or another. Those issues are far more
important to me than some standard which requires interleaving the
applications with the out of the box o/s install stuff.

| (Note that there might be a /usr/include/inn subdirectory someday, so
| trying to stamp out "inn" just to make the subdirectory names
| consistent might be doomed to eventual failure anyway.)

  What I said above;-) It will be /usr/local/include on my systems,
unless some management decrees that a system will conform. As long as I
explain the issues to management in writing.

| > I think this patch should not be committed because it diverges from
| > long estabilished traditions
| 
| I think a more appropriate course of action would be to commit the
| patch, and then quibble over the exact directory locations afterwards.
| As I already stated, I'm open to suggestions on that front.  (Besides,
| I'd like to see the corrected DESTDIR handling make it into at least
| CURRENT and perhaps even STABLE, because the current handling *is* a
| bug, as far as I can tell.)

  There are no "long estabilished traditions" in INN for where to put
FHS optional installs, so there is no issue. If you want FHS, the option
should get conforming FHS, otherwise it should default to "just like
always."

| > and makes wrong (read as: directly in violation of FHS) choices
| > about most files locations.
| 
| I corrected /var/inn (to /var/lib/inn).  I didn't spot any other
| violations--what other violations are you referring to?

  I see places where you could meet the standard and do otherwise, but I
think you have gotten to 'conforming," and I personally don't care
beyond that.

  I agree with the comment about sane distributions not using this
standard, as noted above I think this makes the system harder to admin.
-- 
bill davidsen <davidsen at tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.


More information about the inn-workers mailing list