Date: Sat, 20 Apr 2002 17:06:39 -0700 (PDT) From: Doug Barton <DougB@FreeBSD.org> To: "Philip J. Koenig" <pjklist@ekahuna.com> Cc: stable@FreeBSD.org Subject: Re: /etc/defaults/rc.conf theory Message-ID: <20020420165703.G15643-100000@master.gorean.org> In-Reply-To: <20020420230144663.AAA685@empty1.ekahuna.com@pc02.ekahuna.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 20 Apr 2002, Philip J. Koenig wrote:
> My .02:
>
> There seems to be a few recent situations where fundamental changes
> were made in a way that didn't easily slipstream into the stable
> upgrading process. (ie sendmail changes and the new users necessary,
> which bit me. I think the process of adding those users should have
> been either integrated into the installworld process, or some new
> mechanism for interacting with the system owner/admin should be
> devised.)
I agree that this change was ill advised in its present form.
Gregory just committed a fix to -current that he plans to mfc before the
4.6-release code freeze.
> On that last item and how it relates to /etc/defaults, I agree with
> various other people that I *don't* want a 400-line rc.conf file.
Given that there are only about 250 variables in
/etc/defaults/rc.conf, I think you're safe. :) But seriously folks, no one
suggested that you do that. My (obviously unclear) suggestion was that you
copy that file to /etc, then set the values for the things you care about,
and delete the rest. That way you're safe (relatively), no matter what
happens down the road.
> What I think would be a better way of approaching it is to
> incorporate some method of informing users during the upgrade
> process, probably part of mergemaster, of what has changed in
> /etc/defaults.
Assuming that you run mergemaster, you'll see the diff before
being presented the options to install, delete, etc.
> I think Doug's addition of the -c option is a start, but I don't think
> it goes far enough, personally.
It's -C actually. The -c option does something different.
> A section of mergemaster which prints key "heads up" items pertaining
> to the current build would also be extremely helpful.
This is already there for you in UPDATING.
> Sometimes we forget to read UPDATING,
Oh, well, don't do that. :)
> (sometimes the important info isn't there), sometimes we miss some key
> piece of info amongst all the other stuff in the file, and sometimes we
> just need to be reminded to do something before rebooting and
> discovering the box broke in some unexpected way. (An example of a
> similiar previous improvement in mergemaster was a year or 2 ago when it
> incorporated the re-make aliases and devices feature at the end of the
> merging process, which I think was a excellent idea)
Well, thanks for your kind words in any case. I fear that people
want to put too much on mergemaster's shoulders though. The unix design
philosophy is to create small tools that perform specific functions well,
then combine them in interesting ways. Poor mergemaster has already
bloated way beyond its original purpose... mostly for good reasons, but
bloated none the less. If someone else wants to write an "Upgrade safety
belt script for inexperienced sysadmins," I say knock yourself out.
However, at some point, the person pushing the buttons has to take
responsibility for their actions... No tool, no matter how elegant, is
ever going to replace that need.
--
"We have known freedom's price. We have shown freedom's power.
And in this great conflict, ... we will see freedom's victory."
- George W. Bush, President of the United States
State of the Union, January 28, 2002
Do YOU Yahoo!?
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020420165703.G15643-100000>