Greg A. Woods said:

>Updating /etc/rc.d scripts is not anywhere near so difficult as the rest
>of /etc.  (and for the latter the new etcupdate, though still _very_
>rough around the edges, is already a very huge improvement over anything
>I've ever seen in the past)

Well, my DNS server and main mail server is running 1.5.3RC1 with 
BIND 9.2.1. The newer BIND is installed in /usr/local/sbin. Now I
could turn off BIND in /etc/rc.conf, and start named in /etc/rc.local,
but some of the services in /etc/rc.d need named running. So I hacked the
script to run /usr/local/sbin/named. Later on, when I rebooted, I found that
I also had to hack the script to make sure that all the disks and partitions
were mounted so that /usr/local was mounted.

If I were to upgrade the box to 1.6, I would have to hack the named script
on 1.6, as it appears to be somewhat different than the 1.5.x version of
the script.

Now if I had to do that to all the stuff I might run from rc.local, upgrades
would become a much more labor intensive process.

>Since each script is in a separate file, and provided the rc.subr API
>stays backwards compatible (I'm not sure it has between 1.5 and 1.6, but
>it should from now on), the only issue is with filename clashes, and
>that's a much smaller issue once system files are registered in a
>package, and provided most add-on software is also installed as
>packages -- conflict detection is automatic.

My fervent hope is that a registered pkg database for system files
will be optional. The system I'm sitting in front of is running
NetBSD 1.4.3. Somewhere between 1.3 and 1.4 the location of the pkg
database changed. If I try to add any new packages or upgrade any
existing packages, software disappears and doesn't get rebuilt.

Any software that I add to this machine gets built by hand and installed
in /usr/local now.

I don't see why the flexibility of the OS should be reduced. Removing
/etc/rc.local reduces flexibility.
-- 
Rick Kelly  rmk@rmkhome.com  www.rmkhome.com