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

Re: Proposal: /etc /usr/etc /usr/local/etc




On Fri, 4 Jul 1997, Yann Dirson wrote:

> The FSSTND is there as guide. As long as all requirements can be
> solved cleanly following FSSTND, there's no reason to change it; but
> if we find out that something can't be solved cleanly, then maybe it
> will need to be changed...

No argument from me.  The central question in this case seems to be
how to define "cleanly", and whether the solution presented in the
FSSTND is "clean" enough.

[...]
> OK, let's try to summarize the 2 alternatives:
> 
> Everyone agrees on the fact that site-wide conffiles should be in
> /usr/etc, and local ones in /etc.
> 
> Points get a + when I consider them good, a - if bad, an = if
> non-significant, a ? if I don't have an idea
> 
> 1) conffiles accessed exclusively through /etc, via symlinks if not
> overriden.
[...]
Score:  "+":2, "-":2, "?":1, "=":1

> 2) conffile search-path (either by library or by filesystem):
[...]
Score:  "+":2, "-":2, "?":1, "=":1

> Given that I consider point (c) to be significant only if technical
> issues require equivalent workload, both solutions seem to be quite
> equivalent.

Seems so.

> Did I forget something ?

If implemented by adding a new confopen() function to libc, 
solution (2) would require rebuilding a bunch of packages and
would require negotiations about the changes with FSSTND maintainers
and with linux libc maintainers (these negotiations might fail) if
we're to avoid making debian a linux variant requiring linux-uncommon
programming practices.  To my mind, (2) would have to promise some
very significant benefits compared with (1) to justify going through
that, and I don't see such promise.

My summary regarding (1):
  It's the currently mandated practice, Linux-wide.
  It's not broken, don't try to fix it.



--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .


Reply to: