Re: Hurd FS hierarchy (was Re: LD_LIBRARY_PATH troubles)

[Richard Kreuter]

On Sun, Mar 24, 2002 at 03:36:08PM -0800, Thomas Bushnell, BSG wrote:
> Richard Kreuter <kreuter@ausar.rutgers.edu> writes:
> 
> > The /com hierarchy should contain the following directories:
> > 
> > /com/mail
> > /com/spool/news
> > <...what else?>
> 
> Note that this is true *only* if the relevant software actually
> supports reliable updating by multiple machines at once.  This is not
> usually true for /com/spool/news, and is often not true for
> /com/mail. 

  I see your point, but am about to raise an objection.  Assuming the
ojection is faulty, should the above pair of sentences be included in
the specification of /com for the FHS GNU annex?

  Here's the objection, for consideration: basing inclusion in /com on
the capabilities of the relevant software will keep many things that
should be shareable stuck in /var: if somebody puts together some
program/system that does the right thing by non-host-specific files
(i.e., reliably and correctly updates on multiple machines at once),
then if inferior alternative program/systems are relevant (e.g.,
supported by the distributor, commonly used, etc.), then the better
software/system will be stuck putting files in /var instead of /com.
(I recognize that /com is defined not by host-specificity, but data
shareability, but presumably one wants the non-host-specific data to
be shareable, right?)

> > [Re: /libexec] <Should networking daemons go here?>
> 
> If they are not normally runnable from the command line, yes.  Most
> inetd daemons are in this category, but not all.
> 
> (Some allow for execution as a command in a special debugging mode;
> that's not enough to warrant putting something in {s,}bin.  Such
> things usually belong in libexec.)

  Should slightly modified rewordings of this last pair of sentences
be included in the specification for criteria for inclusion in
/libexec in the FHS GNU annex?

Thanks,
Richard