[ On Tuesday, March 18, 2003 at 18:23:37 (+0100), Tom Ivar Helbekkmo wrote: ]
> Subject: Re: /usr/pkg/etc/rc.d/*
>
> "Greg A. Woods" <woods@weird.com> writes:
> >
> > No, it's not that simple.  Been there, tried that, gave up.  It's just
> > not worth even trying.
> 
> Why?  It *seems* to be working very well for me...  You claim that
> /etc/rc.d/ is a local configuration directory,

Well, no that's not really my claim -- it's much more general than that
and I'm just observing it as fact.

> although the base
> system installation does populate it.

and it does so without keeping default copies, which is why I said that
such treatment may not be as wise as some might think.  Regardless
that's a totally separate issue.

>  All I've done is split it into
> a "system" part and a "local" part.  It works.  What have I missed?

Lots and lots of special cases which are apparently quite common.  What
you've done might be fine and work OK for you for now, but as far as I
can tell it will never be "OK" for the base release which should try to
support all those "special" cases.

You really should ask yourself though exactly why you've split your
system into such separated parts.  I'll bet you can't come up with any
really good and justifiable reason, especially in this context where the
"local" part is a set of managed packages from pkgsrc.

Meanwhile you've created a system where your users (assuming you have
any other than yourself) are forced all too often to have to think about
whether some program they use is an add-on part of just part of the base
system when all they want to do is make use of that program and to do so
without having to specify any platform-specific pathnames.  If you look
back over the history of complaints about what's included by default in
any base OS (i.e. across all unix and unix-like implementations) then
you'll find it's not just developers who whine and complain when their
favourite tools are not included in, and installed in, the base OS
hierarchies.  You'll also find that people, developers especially, will
whine loudest when they have to find their favourite tool in some
"non-standard" path, particularly when that difference means changing
scripts, e.g. the interpreter file path for "#!", etc.  It really is
often a "Good Thing(TM)" to install add-on stuff into the base OS
hierarchies so that it appears to users as if it came with the system.

-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>