Re: FHS

[Guido Draheim]

Es schrieb Akim Demaille:
> 
> >>>>> "Akim" == Akim Demaille <address@hidden> writes:
> 
> >>>>> "Thomas" == Thomas Bushnell <address@hidden> writes:
> Thomas> Russ Allbery <address@hidden> writes:
> >>> Personally, I'm somewhat annoyed to see yet more paths going into
> >>> Autoconf that I'll then have to override to get the installation
> >>> paths that I want (namely a flat tree of bin, sbin, lib, man,
> >>> info, and etc); with over five hundred packages installed that way
> >>> and using automated tools to maintain Stanford's shared software
> >>> tree, I have no intention at the present time of changing our
> >>> package layout.  But I suppose I can always continue to override
> >>> all the individual paths like I already have to do for
> >>> sharedstatedir, libexecdir, and datadir.  (Of course, GNU gettext
> >>> has a habit of blissfully ignoring the datadir setting given at
> >>> configure time in favor of hard-coding share.  And I'm not sure
> >>> anything actually uses sharedstatedir and libexecdir except
> >>> Emacs.)
> 
> Thomas> The changes here for the GNU Coding Standards (which I'm
> Thomas> proposing, and RMS has now agreed to) will not add any new
> Thomas> paths, it will simply change some that currently exist.
> 
> Akim> Could someone summarize these changes?  I have not seen them in
> Akim> standards.texi, although I just updated them :( Can someone
> Akim> point me to where Autoconf ought to be adjusted?
> 
> What were these changes wrt the documentation and the FHS, please?
> Anything that needs one of Automake or Autoconf to be adjusted?


according to the FHS, the actual system of subpaths does depend
on the prefix itself (- a package to be installed into /opt/name will
have its configfiles in /etc/opt/name -) so basically you have to
choose a default behaviour from the range of possibilities that
have been documented in the FHS. In a way, the FHS documents the set
of *existing* practices, and tries to modify it almost minimally, to
make it more methodic, e.g. that system-wide installations may end up 
on a readonly-mounted device, so that its ./var and ./etc are usually
put somewhere else. To a certain degree, the FHS sections about
/usr/local packages might best fit the scheme of gnu autotools,
since the /usr/local prefix was the default for gnu autoconf'ed
packages for a long long time, and therefore the corresponding FHS 
section does follow these old defaults in large parts.

If you look into it, you will find that it calls for /usr/local/man
whereas exactly this man-subdir had been the largest nuisance for
many people. Same for the info-subdir, which has been mentioned
only as /opt/info followed by with /opt/man. Personally, I would
still argue one should move all doc-like files into share, but I'm
not the FHS guy, ye know. 

/so much, so good/

To go on with personal opinions, I have only one specific preference 
as to $sharedstatedir, which is not mentioned in the FHS. About no 
one used it so far, atleast with its default being $prefix/com/ which 
was not seen anywere, so no developer has an instant association 
with this subpath. I think that developers will pick it more easily
and *intuitivly* if it would be moved as a subpath of another. And
yes, I'd value a more intuitive set of prefix/subpaths anyway, just
like it is (of course!) a good idea to move all doc-like files into
the $datadir subpath - (which has the attribute of being read-only
architecture-neutral) - so, yes, personally, still I would argue in 
favor of moving $mandir and $infodir and put them as dependent on
$datadir by default, just like it is done for /usr packages in FHS.
This makes the default installation-layout much more intuitive to
developers, and I see it as a sane modification over just honouring
tradition with a traditial gnuish /usr/local layout. I guess, if we
make a poll amongst developers, we'll see that the gnu autotool
users would prefer that change over being stuck in tradition things,
even if they would have to check their packages to be ready to
accept this change - it is a good *CHANGE*. Referring to FHS isn't
actually needed, just take opinions...

-- guido