Frederick Bruckman <fredb@immanent.net> writes:

> Besides, it's not true that "rc.d" has no user configurable parts
> inside. As we've totally failed to come to any agreement on how to
> handle pkgsrc rc.d scripts, we tell people to copy them into rc.d
> themselves.

Leading me to wonder out loud if maybe there shouldn't be two stages
of rc.d, for example's sake call them "/etc/rc.d.defaults" (or maybe
/etc/defaults/rc.d) and "/etc/rc.d". The former would contain the
"factory" versions of all the files, and would be automatically
updated by a make build, or a binary upgrade, while the latter would
not be touched by either operation. The two directories would be
treated kind of like a union file system, with files in /etc/rc.d
taking precedence over the same file in /etc/rc.d/defaults.

> [...] I have learned my lesson not to try to customize anything in
> "/usr" that would be overwritten, but "/etc" is supposed to be the
> safe haven.

And *that* makes me wonder if maybe all the immutable things in /etc
could be moved elsewhere (/lib or /libdata maybe?)(yes, I know neither
of these exist right now). Aside from /etc/defaults and /etc/rc.d,
there's rc.subr, possibly rc.shutdown, and ??? Other things have
migrated out of /etc (eg, dhclient-script)

Okay, now go ahead and rip these ideas apart ;-)

I agree, btw, that having the update of all this stuff done
automatically would be nice.  It only takes a 5 minute trip with
dirdiff to update /etc from the latest sources by hand, but it would
be nice to not need to remember to do it.