Filesystem Hierarchy Standard (FHS) compliancy?
qralston+ml.inn-workers at andrew.cmu.edu
Thu Mar 22 21:21:28 UTC 2001
On Wed, 21 Mar 2001, Marco d'Itri wrote:
> The only INN binary which is usually executed by an user is ctlinnd,
> which in my debian packages I install in /usr/sbin. Everything else
> goes to /usr/lib/news/bin, I don't want to pollute the path with
> mostly useless binaries. To use most of them you have to su - news
> anyway or you'll probably create file with the wrong owner.
That's true, but that really doesn't matter. According to the FHS,
the /usr/bin and /usr/sbin directories are supposed to contain
binaries that are useful to regular users, and binaries that are
useful to the "system administrator" (respectively). The
interpretation of "system administrator" that most people seem to
agree on is "the root account or some other special 'system' account".
Under the FHS, the cnfsstat, convdate, fastrm, grephistory, inndf,
nntpget, sm, simpleftp, and shrinkfile programs (just off the top of
my head) are all potential candidates for /usr/bin. The ctlinnd,
inncheck, innstat, makeactive, makehistory, and prunehistory programs
(again, just off the top of my head) are all potential candidates for
/usr/sbin. Any program that's not designed to be invoked directly by
a user or system administrator in any way should be thrown into some
subdirectory of /usr/lib/inn.
> > Provided that any new configurable directories inherit the same
> > values as they currently have if they aren't explicitly set
> > (either by hand, or with the option that enables FHS compliance),
> > and that the creation of new configurable directories is kept to
> > the minimum required to enable a --with-fhs-compliance option to
> > work properly, do we care if more configurable directories are
> > created?
> > If your answer to my question of "Do we care if more configurable
> > directories are created?" is "yes", then please just say so
Given the information in my "Provided that..." paragraph: why do you
feel this way?
I can understand that adding more configurable directories has the
potential to increase confusion, but when the consequence of *not*
adding more configurable directories is even more confusion among the
vendors who build and package INN, what is the point?
> And the examples you described so far can be easily solved by moving
> files in the package building script.
> I really would like to see the modifications needed to install INN
> strictly conforming to the FHS be included so that each Linux
> distribution stops trying to do it themselves.
I agree with Russ (except that I would append "...and screwing it up"
to his sentence). But you are proposing the exact opposite--that we
give Linux distributors a package that cannot be automatically built
and installed in conformance with the FHS without a lot of
hand-tweaking and relocating of files and programs.
What I *thought* we wanted was to be able to say:
$ ./configure --prefix=/usr --with-fhs-compliance
$ make prefix=/tmp/inn-build-root/usr install
...and have everything go exactly where it's supposed to go under the
FHS. That's what package builders are used to, and they won't screw
Is this what we want? If so, are we willing to add more configurable
directories to do it?
James Ralston, Information Technology
Software Engineering Institute
Carnegie Mellon University, Pittsburgh, PA, USA
More information about the inn-workers