Date: Sat, 20 Apr 2002 16:01:43 -0700 From: "Philip J. Koenig" <pjklist@ekahuna.com> To: stable@FreeBSD.ORG Subject: Re: /etc/defaults/rc.conf theory Message-ID: <20020420230144663.AAA685@empty1.ekahuna.com@pc02.ekahuna.com>
next in thread | raw e-mail | index | archive | help
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.) 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. And while I agree in theory of the idea of periodically 'copying' the /etc/defaults/rc.conf to /etc and weeding through it, in practice I really don't think this is workable. (most of us just won't do it often enough, and this is one reason I think many of us prefer FreeBSD's system of defaults/overrides to various other *nix OS's configuration hairballs.) 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. I think Doug's addition of the -c option is a start, but I don't think it goes far enough, personally. What would be really cool is a mechanism in mergemaster that reads the version info in your current /etc/defaults/rc.conf file (for those of us that don't update frequently), and then spits out a list of changes made since that file was last updated. (as Mike Meyer noted, including changes in syntax which wouldn't be picked-up by a simple diff) A section of mergemaster which prints key "heads up" items pertaining to the current build would also be extremely helpful. Sometimes we forget to read UPDATING, (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) Thanks for listening. -- Philip J. Koenig pjklist@ekahuna.com Electric Kahuna Systems -- Computers & Communications for the New Millenium 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?20020420230144663.AAA685>