Date: Thu, 27 Aug 1998 14:35:32 -0700 From: Studded <Studded@dal.net> To: Matthew Dillon <dillon@backplane.com> Cc: Bruce Evans <bde@zeta.org.au>, jkoshy@FreeBSD.ORG, committers@hub.freebsd.org Subject: Re: cvs commit: src/etc make.conf Message-ID: <35E5D124.EE0E4202@dal.net> References: <199808270547.WAA11311@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Matthew Dillon wrote:
Bruce wrote:
> :Yes, I already object to it checking for /etc/make.conf :-). The top
> :level is too high for most of the stuff in it. It should only be used
> :to override or add to settings for variables like CFLAGS that are already
> :set in <sys.mk>.
> :
> :Bruce
>
> IMHO, make.conf as it currently stands is an important
> 'official' file.
Nothing personal, but that's kind of a silly view. Everything that
ships with FreeBSD belongs to you, and you can change it according to
your whim. You just have to know what you're changing and what the
(likely) results will be.
> If you get rid of the 6K of official
> stuff in it, you might be able to call it a local file.
> But until you do, it sure *isn't* a local file or a
> locally editable file.
I re-edit make.conf every time it gets updated. Of course, I only
uncomment 8 things so I don't think of it as a major task.
> It doesn't matter whether the
> stuff is commented out or not. It's critical information
> that needs to be updated on every release, therefore
> we (BEST) or I (personally) would rather not have to re-copy
> and re-merge the file every time we do a major system
> update.
You've just proven why your suggestion is a bad thing. What happens if
the format of an important variable that your system depends on is
changed in a new version of the file? You will miss the change and your
make.conf.local will now not be doing what you expect it to. Admittedly,
this should not happen with any degree of frequency, however the
possibility is there.
> Having a make.conf.local completely solves the problem.
> It is a 100% fix and removes yet another file from having
> to be re-merged after an update.
Actually, you haven't re-moved the problem you've just moved it. What
you're promoting here is something similar to a make.conf LINT file,
with the concurrent problems attached.
> It is also, I might add,
> relatively critical that such re-merges be done properly
> with the current scheme. The last thing I want to do
> is accidently leave out a custom kerberos define that
> breaks 40 rack-mount FreeBSD boxes!
And if this is something mission-critical to your installation, you
will want to double-check the new make.conf against the current options
that you're using anyway, so how does the system you propose make this
task easier than merging the changes to make.conf by hand?
> make.conf.local solves the problem, neatly and succinctly.
A) I don't see the problem (if there is one) in the same way you do, so
I disagree with your premise.
B) If there is a problem as you describe it, your potential solution
merely hides it away, it doesn't actually solve anything. Therefore I
also disagree with your conclusion.
Rather than using these types of kludgy solutions to ill-defined
problems we should be working on better tools to upgrade/merge
configuration files to start with. Of course my view is biased, because
I am actually working on such a tool. However I still believe that this
make.conf.local is a bad idea, as is splitting configuration for the
same items into two seperate locations (e.g., /etc/rc.conf and
/etc/local/rc.conf).
Doug
--
*** Chief Operations Officer, DALnet IRC network ***
When you don't know where you're going, every road will take you there.
- Yiddish Proverb
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?35E5D124.EE0E4202>