From owner-cvs-all Thu Aug 27 14:37:18 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA05223 for cvs-all-outgoing; Thu, 27 Aug 1998 14:37:18 -0700 (PDT) (envelope-from owner-cvs-all) Received: from dt053nb4.san.rr.com (dt053nb4.san.rr.com [204.210.34.180]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA05116; Thu, 27 Aug 1998 14:36:52 -0700 (PDT) (envelope-from Studded@dal.net) Received: from dal.net (Studded@localhost [127.0.0.1]) by dt053nb4.san.rr.com (8.8.8/8.8.8) with ESMTP id OAA08434; Thu, 27 Aug 1998 14:35:33 -0700 (PDT) (envelope-from Studded@dal.net) Message-ID: <35E5D124.EE0E4202@dal.net> Date: Thu, 27 Aug 1998 14:35:32 -0700 From: Studded Organization: Triborough Bridge & Tunnel Authority X-Mailer: Mozilla 4.06 [en] (X11; I; FreeBSD 2.2.7-STABLE-0823 i386) MIME-Version: 1.0 To: Matthew Dillon CC: Bruce Evans , jkoshy@FreeBSD.ORG, committers@hub.freebsd.org Subject: Re: cvs commit: src/etc make.conf References: <199808270547.WAA11311@apollo.backplane.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-cvs-all@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk 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 . > : > :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