Subject: Re: /etc/default ickiness...
To: Luke Mewburn <email@example.com>
From: Greywolf <firstname.lastname@example.org>
Date: 09/15/2000 15:07:55
On Fri, 15 Sep 2000, Luke Mewburn wrote:
# Date: Fri, 15 Sep 2000 19:04:32 +1100
# From: Luke Mewburn <email@example.com>
# To: firstname.lastname@example.org
# Cc: John Nemeth <email@example.com>
# Subject: Re: /etc/default ickiness...
# John Nemeth writes:
# > On Jan 31, 6:04pm, Luke Mewburn wrote:
# > } > Perhaps this could be based on how folks typically track kernel config
# > } > file changes - keep a copy of the default file, and diff that against
# > } > a copy of the new default file to see what needs to be changed in the
# > } > actual in-use file. I'm sure this could be automated easily enough to
# > } > take much of the grunt work out of it.
# > This was one of the suggestions that was made in a previous
# > discussion about this topic. This idea makes a lot of sense and would
# > be a perfect solution to the problem at hand. Another suggestion was
# > to use RCS, but I think that would be overkill for most sites.
# > However, as long as it didn't get in my way, like the current change
# > does, I wouldn't object.
You know, I was going to hop on the bandwagon down the flame-licked
bumpy road and decided that it wasn't worth the grief. It still isn't.
I just tried the new scheme (i.e. it looks at default/rc.conf and applies
overrides in rc.conf), and overall I'm actually pleased with this.
I'm not thrilled about the rc.conf.d stuff suddenly showing up, but
at the moment it appears that actually USING rc.conf.d is optional.
If this was by design, I will say kudos and THANK YOU to Luke for
the work he's put in here -- I don't envy him what he's had to put up
with in the form of abuse from myself (among others) on this road.
He's been kind enough to either respond nicely or completely ignore it,
at least to me.
I like /etc/default/rc.conf + /etc/rc.conf. The re-tuning of startup
for me actually took less time to do this way than it did last time
I had to retune it.
I have a suggestion for the "xdm" and "xfs" rc.d scripts and anything else
The base X directory needs to be variable. I discarded the R6 from
my X distrib (i.e. it's /usr/X11) right after R6 came out and made
# I don't appreciate you criticising us for suggesting that you use
# a manual page in a given release relevant to a change added in that
# release. That's like complaining that new ftp features that would be
# first visible in 1.5 weren't documented in 1.4.2...
I'll agree with this -- the man pages are one of the first places I
look when something doesn't quite work as expected.
# I don't think there is One True Way for supporting upgrades of
# configuration files, especially given that NetBSD (unlike commercial
# OS releases) has to cope with people upgrading from a release or
[I think this was the argument that others were trying to make at
one point against splitting out /etc/rc; it turns out that this
is probably easier to do now than under a monolithic rc. I still
think the aesthetic output from the current method is not as warm
fuzzy at boot time, but oh, well. That's cosmetic and I have a work-
around (which now needs updating).]
"The source is strong with you, young Vaxhacker."
BSD: Stop, Drop, and Load