From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17731 invoked by uid 1002); 7 Sep 2003 10:45:03 -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 16523 invoked from network); 7 Sep 2003 10:44:59 -0000 From: Martin Schlemmer Reply-To: azarah@gentoo.org To: Troy Dack Cc: Gentoo-Dev In-Reply-To: <1062922741.7363.26.camel@waterhouse.internal.lan> References: <1062896271.20020.28.camel@vertigo> <1062904114.8455.62.camel@nosferatu.lan> <200309070559.21887.jk@microgalaxy.net> <1062922741.7363.26.camel@waterhouse.internal.lan> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-fdj3eWqMDjAZhKqj32Ro" Message-Id: <1062931703.8455.80.camel@nosferatu.lan> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Sun, 07 Sep 2003 12:48:23 +0200 Subject: Re: [gentoo-dev] Some suggestions X-Archives-Salt: 84a98ba6-8ebf-40a8-b77d-c5e30ba82b2b X-Archives-Hash: 715dd95467c7b5d4fe738585d5c75926 --=-fdj3eWqMDjAZhKqj32Ro Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sun, 2003-09-07 at 10:19, Troy Dack wrote: > On Sun, 2003-09-07 at 15:59, Jan Krueger wrote: > > 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, >=20 > I'd say 95% of user, but that's just me :P >=20 > > From my point of view the best for the 90% of users in this case (make.= conf)=20 > > would be: > > 1. a very precise documentation with examples about the user settable t= hings=20 > > for make.conf thats accessable via a standard command, like man make.co= nf or=20 > > info make.conf >=20 > How imprecise and unaccessible is: >=20 > nano -w /etc/make.conf >=20 > All settings are commented, and commented well, and it's available using > standard commands (you could even use ed or a combination of cat, less, > head & tail if you really wanted to) >=20 > > 2. a clean, easy to read configuration file without mess and things the= user=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 easie= r to=20 > > identify the place where the change must happen and easier to identify = the=20 > > values that already are there. >=20 > OK, I've installed Gentoo on my boxes that many times I know the process > pretty much off the top of my head, however I can't remember all of the > FEATURES that are available, having them listed in make.conf is > beneficial. >=20 > > You may try this yourself: > > nano -w make.conf as it gets installed > >=20 > > and > > nano -w make.conf with just the settings you actually use, everything e= lse=20 > > thrown out. >=20 > grep -v "#" /etc/make.conf|wc -l && wc -l < /etc/make.conf > 31 > 290 >=20 > Fair enough, I've got 259 lines of comments, I can live with that, the > file isn't confusing and the options are grouped sensibly. >=20 > It seems to me to be fairly standard Linux practice to provide a well > commented config file that can be modified slightly as suited, eg: >=20 > grep -v "#" /etc/squid/squid.conf | wc -l && wc -l < > /etc/squid/squid.conf > 258 > 3231 >=20 > So, I've got nearly 3000 lines of comments in my squid.conf, I bet you > won't see anyone suggesting that squid gets installed with an empty > config file and you have to roll one by hand. >=20 > > Which one is easier to modify?=20 > > Especially try to change a FEATURE setting. Or even better, let a new g= entoo=20 > > user try to change a FEATURE setting. > > > > If the user is not sure about the variables/values to put there the use= r may=20 > > at anytime suspend nano or open another terminal or use another virtual= =20 > > console and execute man make.conf >=20 > So it is easier to explain to a newbie that they need to switch to a > new virtual console, start up the documentation viewer (man, less, > lynx), read through the docs, switch back to the other virtual console, > make a few changes in the file, lather, rinse, repeat. >=20 > I'll differ with your opinion here, I think it is much easier to have a > well commented file (same as reading code, if the comments are in the > code, it's easier than referring to a description of it and trying to > read the code). >=20 > > most users probably use just 4 or 5 settings: > > use flags > > c(xx) flags > > sync > > mirrors > > features >=20 > True, those are probably the only ones people set, but they are some of > the most important ones in the system. >=20 > Having a config file that lists only the variables to be changed will > lead to people swapping conf files ("Here, use this one it is all set > and works well for me") which could in turn lead to more problems > because people have settings enabled/disabled and they don't know why, > or what those things do. >=20 > > the rest is for the majority of users just useless in make.conf. So my=20 > > expirience (and assumption). > >=20 > >=20 > > 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 h= old > > > 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? Shoul= dn't > > > it be in make.globals or better yet the man page? > > > > > > make.conf is used for system customization and, as such, portage shou= ld > > > 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. >=20 > Given that a very, very, very large portion of the questions that get > fielded on #gentoo are the result of a significant lack of RTF'ing M I > don't think having an empty file is the way to go, #gentoo would just > degenerate into "RTFM" responses (of which I am pleased to say that > generally there are not *that* many). >=20 > [see above re: swapping of config files as well] >=20 > > 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 int= end 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 bec= ause i=20 > > want a feature/useflag or whatever. So then, and only then, i edit this= file=20 > > or let a tool edit it (eg: euse). >=20 > etc-update, merge files, half a dozen l's, a couple of r's, the odd eb > and it's all done, new FEATURES merged in, old settings left intact. >=20 > Not hard, plus I am now aware of what new things are available. >=20 > > 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 doe= s it: > > mark the old thing as deprecated and warn the user for some time|versio= ns to=20 > > give the user time to get informed and do the change manually or by usi= ng a=20 > > dedicated tool. > >=20 >=20 > "Gentoo moves pretty fast; if you don't stop and look around once and > awhile, you could miss out." Amen --=20 Martin Schlemmer Gentoo Linux Developer, Desktop/System Team Developer Cape Town, South Africa --=-fdj3eWqMDjAZhKqj32Ro Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQA/Wwz3qburzKaJYLYRAoRPAJ9lzG6Ino3HPhlWdKeOhFTvsOHwrACgje/B yuk/Qhgetj/aQl+T8M/DqQU= =TrfB -----END PGP SIGNATURE----- --=-fdj3eWqMDjAZhKqj32Ro--