From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26942 invoked by uid 1002); 7 Sep 2003 03:53:56 -0000 Mailing-List: contact gentoo-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Received: (qmail 14690 invoked from network); 7 Sep 2003 03:53:56 -0000 From: Jan Krueger Organization: microgalaxy.net To: azarah@gentoo.org, Chris Gianelloni Date: Sun, 7 Sep 2003 05:59:21 +0000 User-Agent: KMail/1.5.2 Cc: Steven Elling , Gentoo-Dev References: <1062896271.20020.28.camel@vertigo> <1062904114.8455.62.camel@nosferatu.lan> In-Reply-To: <1062904114.8455.62.camel@nosferatu.lan> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200309070559.21887.jk@microgalaxy.net> Subject: Re: [gentoo-dev] Some suggestions X-Archives-Salt: 7cb0485a-4fc8-4195-bd15-5f03b6848e49 X-Archives-Hash: 143d7a546bf768d5eeb2527b5ae20caa On Sunday 07 September 2003 03:08, Martin Schlemmer wrote: > Come on guys, think what is best for the *distro* (meaning, > what will work best for the other 90% of users, =46rom my point of view the best for the 90% of users in this case (make.co= nf)=20 would be: 1. a very precise documentation with examples about the user settable thing= s=20 for make.conf thats accessable via a standard command, like man make.conf o= r=20 info make.conf 2. a clean, easy to read configuration file without mess and things the use= r=20 doesnt care about so it is easy for the user (even easier for tools) to=20 change exactly the setting the user wants to change because it is easier to= =20 identify the place where the change must happen and easier to identify the= =20 values that already are there. You may try this yourself: nano -w make.conf as it gets installed and nano -w make.conf with just the settings you actually use, everything else= =20 thrown out. Which one is easier to modify?=20 Especially try to change a FEATURE setting. Or even better, let a new gento= o=20 user try to change a FEATURE setting. If the user is not sure about the variables/values to put there the user ma= y=20 at anytime suspend nano or open another terminal or use another virtual=20 console and execute man make.conf most users probably use just 4 or 5 settings: use flags c(xx) flags sync mirrors features the rest is for the majority of users just useless in make.conf. So my=20 expirience (and assumption). So i strongly support: On Saturday 06 September 2003 23:48, Steven Elling wrote: > Requiring portage updates to make.conf at all has always bugged me. The > file is meant to contain custom settings for portage and to append to or > override variables in make.globals and the defaults. It should not hold > all the documentation for make.conf. It should not hold all the > defaults... that's what make.globals and the defaults are for. > > Why is all the documentation on make.conf in make.conf anyway? Shouldn't > it be in make.globals or better yet the man page? > > make.conf is used for system customization and, as such, portage should > leave it alone. When portage is installed on the drive for the first time > it should not create make.conf. Portage should leave it up to the > admin/user of the box to create the file. Thats sound like a clean solution to me. Thats the way it should be. I refuse to update my customised and over the time grown settings in=20 /etc/make.conf with /etc/make.conf with comments for things i never intend = to=20 use. That doesnt make any sense to me to put such useless comments with=20 documentation that has to be in the man page anyway in a file thats so=20 important for my system. I refuse to let anything automaticly update this file. I refuse to touch this file until there is a strong need to edit it because= i=20 want a feature/useflag or whatever. So then, and only then, i edit this fil= e=20 or let a tool edit it (eg: euse). If a change, because of a new advanced portage version, to my existing=20 settings is needed, this change should be delayed as other software does it: mark the old thing as deprecated and warn the user for some time|versions t= o=20 give the user time to get informed and do the change manually or by using a= =20 dedicated tool. Jan -- gentoo-dev@gentoo.org mailing list