help-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Thomas Bushnell, BSG
Subject: Re: Hurd FS hierarchy (was Re: LD_LIBRARY_PATH troubles)
Date: 25 Mar 2002 13:54:27 -0800
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1

Richard Kreuter <kreuter@ausar.rutgers.edu> writes:

>   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?)

In general, there is no need to specify most of this.  There is a kind
of reflexive specification in fhs that is not necessary.

When a program changes to permit sharing, the data should then be
fetched from /com, and if you haven't reflexively decided "it will
always be in /var", then this is convenient and easy.

>   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?

I would probably borrow relevant text from the Makefile standards.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]