On Sun, Mar 18, 2007 at 11:01:22AM -0400, Greg Troxel wrote:
> One concern I have about your naming change proposal is that it seems
> to sort everything into "system" and "local".  But, there is a third
> category "pkgsrc".  Currently, pkgsrc can install into rc.d, and that
> seems to work quite well.

Naming are conventions. I used local because there was already rc.local
and other stuff. Better name would be "site", but it is just a matter of
convention.
pkgsrc are "local" additions. If this is not a problem putting pkgsrc
scripts into /etc/rc.d/, why don't we simply put everything under /bin
or /sbin ;)

Segregating things allows to suppress roughly with a rm -fr
<dedicated_dir> with perhaps problems, but not disaster if the base
system is still here.

Since rcorder(8) orders everything, and that the rc(8) framework calls
in order every script which "decides" by itself to run or not depending 
on the variables values, being able to safely remove unneeded local|site
additions to speed boot process is a plus.

When doing an upgrade on a node, postinstall(8) is already a problem
because one does not have the sources in all the cases. So running a
diff against a reference tree is not always an option.

I have a build framework that allows me to "patch" a NetBSD vanilla
install, changing files with a very versatile installation scheme. So
there is no technical problem, but I was not satisfied and I wanted to
put things a little further.

Adding /etc/rc.d.local/ offers only one supplementary indication, without
adding overhead or changing behavior. It is all benefits.

But when one comes to administration the important thing is to be
comfortable with your tools or the way you organize things. This is, in
part, a matter of taste (but there are basic principles; simplest is
best).

I sent the patches to document a little more the rc start up process, so
that it can be here to perhaps help others to discover possibilities,
and help them ask themselves questions (one finds several tips about
NetBSD local daemon addition, and they are not as good as they may be).

Since I'm not a NetBSD developer, the proposal is here FWIW. I have
adopted this scheme for my own administration framework (I'm a
developer; I do administration because I have to, and I want to dedicate
to this the least number of cycles possible: bulk installations, bulk
upgrades and the least to remember to find the source of a problem if
one appears).

Cheers,
-- 
Thierry Laronde (Alceste) <tlaronde +AT+ polynum +dot+ com>
                 http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C