Filesystem Hierarchy Standard (FHS) compliancy?

[James Ralston]

On 11 Aug 2000, Russ Allbery wrote:

> I understand that.  However, in my experience, it doesn't work.  I'm
> one of the people who has to answer questions from those people when
> they can't get INN to work, and I've seen that in practice Red Hat's
> layout causes those people to be unable to find the files that they
> need to configure INN.

I can appreciate the fact that you get pestered with these questions,
but I believe this is the transitional nature of the FHS.  The people
who ask you these questions are probably people who haven't dealt much
with FHS systems, and because of this, they don't yet know where to
expect things to be.

As a counterexample, I was able to locate the config files for
OpenLDAP on my Red Hat box, without "cheating" by using "rpm -qc" to
tell me where the config files were.  The only information I needed
was a recollection of the FHS, and the knowledge the Red Hat tries to
conform to it.  I think within a few years at most, most novice system
administrators will be able to similarly generalize.

> I have no intention of installing INN anywhere other than /var/news
> on any server that I run.  I want the entire package in one place so
> that I can add /var/news to my cdpath and easily get to what I need
> to get to without bouncing all over the whole file system.

> We may have to agree to disagree on this, then.

That's fine.

As INN currently stands, you have the option of configuring INN this
way.  It would be nice if people who found the FHS layout easier to
work with (as I do) had the same option.

> Binaries don't belong in /usr/lib according to the FHS; they go in
> /usr/libexec.  Or have they changed it again?  (Another of my
> problems with the FHS.)

The /usr/libexec directory is from the GNU coding standards, not the
FHS.  According to the FHS, /usr/lib is for "object files, libraries,
and internal binaries that are not intended to be executed directly by
users or shell scripts"; /usr/libexec doesn't exist in the FHS
(although it was a close vote).

> I think you're drastically underestimating how hard it is to keep
> track of where you're supposed to go next in the file system if
> you're very familiar with INN but not familiar with the FHS.

Perhaps, but the solution I would advocate in that instance is "become
familiar with the FHS".  Honestly, it's not rocket science.  ;)

> I'd really rather not make configure take even *more* options, yes.
> What I'd rather see is something like --enable-fhs or something
> similar that fixes all the paths to conform to FHS.

IMHO, you'll still need hooks for setting most of the important
directories, in cases where --enable-fhs-conformity (or whatever) does
mostly (but not completely) the correct and/or desired thing.

However, I think by tweaking the existing /usr/local/news hierarchy
slightly, it would be possible to offer the hooks needed to achieve
FHS conformity without notably increasing the number of arguments
configure accepts.  (Heck, it might even be possible to eliminate some
of the options.)

> I'd rather not make people add two different paths to their PATH in
> order to find the INN programs they need to run.  I'd prefer to
> combine sbin and bin by default.

Actually, come to think of it, *is* there actually any component of
INN that would be useful in the path of end users?  The inews program
is the only one that springs to mind, but I think that's debatable.
Perhaps there's no need for a /usr/local/news/bin directory at all;
perhaps /usr/local/news/sbin would suffice.

> > Do away with --with-lib-dir and distribute the files which
> > currently live there as follows:
> 
> >     /usr/local/news/etc/innshellvars
> >     /usr/local/news/etc/innshellvars.pl
> >     /usr/local/news/etc/innshellvars.tcl
> 
> No, these belong in lib.

Yeah, I can see that argument.  I wouldn't object if they were placed
in /usr/local/news/lib.

> >     /usr/local/news/lib/docheckgroups
> 
> This belongs in bin (or sbin).  I run this directly all the time.

Agreed.

> Other than that, I do see your point, as much as I disagree with you
> about the FHS.  :)  I'll take a look at making this easier to do in
> 2.4.0.

Do you have a particular interest in doing this yourself, or would you
be willing to accept patches?

I ask because my providing a patch and then tweaking it so that it's
acceptable might be faster than you providing a patch and then
similarly tweaking it based on feedback...

Depending on how industrious I'm feeling, I might make up a patch for
either 2.2.3 or 2.3.0 as well...

James