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

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



On Thu, 3 Jul 1997, Yann Dirson wrote:

> Vadim Vygonets writes:
> > On Tue, 1 Jul 1997, Yann Dirson wrote:
> > 
> > > Then I guess that having some sort of "search path" for config files,
> > > that is looking first if /etc contains a conffile, and only if not,
> > > taking the one installed in /usr/etc. This could even be made to use
> > > conffiles for groups (sub-sites) of computers, by using
> > > /etc:/nfs/mygroup/etc:/usr/etc as a search path.
> > 
> > Cool.  I agree it's cool.  It will take more work than my simple
> > standard solution, but it's nice.
> > 
> > > You probably spotted the problem: this would probably require to
> > > change individual programs to conform to this, and it would be quite
> > > difficult to have all programs work like that. We could probably speed
> > > up theconversion process by providing a library to handle that.
> > 
> > Not a shared lib, tho.  Statically linked one.  I can write it (after
> > all, this mess was my idea).
> 
> Why not a shared lib ?

It will (if it will exist) have one function:
FILE *confopen(const char *path);
It will just try to fopen /etc/path, if it fails -- fopen
/usr/etc/path, if it fails, return NULL.  Making a shared lib for it
is ridiculous, as is adding it to libc *shrug*.

> > > Another solution, probably needingless work, wouldbe to implement
> > > some mechanism in the filesystem driver (yes, I do seem to like this
> > > kind of ideas :) to make all reference to an inexistant file under
> > > /etc be handled as a link to a file of the same name under
> > > /usr/etc. That would be some sort of "default link" associated with a
> > > directory. Such a mechanism, when properly detected by autoconf and
> > > handled by user-programs, might help other programs too (though I
> > > hardly see which ones for now :)
> > 
> > Nah.  It'stoo hairy for this simple thing.  I think the first
> > solution is better. 
> 
> It'd be available more quickly than if you had to hack all
> packages... and at least it'd be a good exercise implementing that!
> Maybe I could find some time to do that ?

Ya mean, kernel?  Or something amd-like?  It still looks to hairy for
our goal, but tell me more.

> > I repeat: look at other Unices.  Their solution is as simple as it can
> > be: a config file in /usr, that's all.  But your first solution is
> > acceptable, too.
> 
> Yes, these other unices' solution seems far less general...

What do you mean?

Salut,
Vadik.

--
Vadim Vygonets * vadik@cs.huji.ac.il * vadik@debian.org * Unix admin
The fish doesn't think, because the fish knows...  everything.
	-- Arizona Dream


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