Richard Kreuter <[EMAIL PROTECTED]> 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. _______________________________________________ Help-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/help-hurd
