Re: [gentoo-dev] Some suggestions

[Jason Stubbs]

Hmmm... Next time I'll think before posting.

After reading this discussion, I'd have to say that I'm in the 95%. However, 
if we get back to the root of the problem, there'll probably be a little bit 
less tension.

I think we all know what the problem is - maybe annoyance is a better word. 
I've had several times where I've had to update make.conf but the only thing 
that had changed is comments. One time there was not even any new 
functionality listed, only clarification in the existing comments.

Having said that, I can't offer a solution that isn't more trouble than it's 
worth. In fact, most solutions would break the standard way of configuring 
other files.

Nothing really to offer except to bring (some of) you guys back in to focus. 
Toodles for now.

On Sunday 07 September 2003 17: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,
>
> I'd say 95% of user, but that's just me :P
>
> > From my point of view the best for the 90% of users in this case
> > (make.conf) would be:
> > 1. a very precise documentation with examples about the user settable
> > things for make.conf thats accessable via a standard command, like man
> > make.conf or info make.conf
>
> How imprecise and unaccessible is:
>
> 	nano -w /etc/make.conf
>
> 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)
>
> > 2. a clean, easy to read configuration file without mess and things the
> > user doesnt care about so it is easy for the user (even easier for tools)
> > to change exactly the setting the user wants to change because it is
> > easier to identify the place where the change must happen and easier to
> > identify the values that already are there.
>
> 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.
>
> > 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 thrown out.
>
> grep -v "#" /etc/make.conf|wc -l && wc -l < /etc/make.conf
>      31
>     290
>
> 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.
>
> 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:
>
> grep -v "#" /etc/squid/squid.conf | wc -l && wc -l <
> /etc/squid/squid.conf
>     258
>    3231
>
> 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.
>
> > Which one is easier to modify?
> > Especially try to change a FEATURE setting. Or even better, let a new
> > gentoo user try to change a FEATURE setting.
> >
> > If the user is not sure about the variables/values to put there the user
> > may at anytime suspend nano or open another terminal or use another
> > virtual console and execute man make.conf
>
> 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.
>
> 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).
>
> > most users probably use just 4 or 5 settings:
> > use flags
> > c(xx) flags
> > sync
> > mirrors
> > features
>
> True, those are probably the only ones people set, but they are some of
> the most important ones in the system.
>
> 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.
>
> > the rest is for the majority of users just useless in make.conf. So my
> > 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.
>
> 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).
>
> [see above re: swapping of config files as well]
>
> > I refuse to update my customised and over the time grown settings in
> > /etc/make.conf with /etc/make.conf with comments for things i never
> > intend to use. That doesnt make any sense to me to put such useless
> > comments with documentation that has to be in the man page anyway in a
> > file thats so 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 want a feature/useflag or whatever. So then, and only then, i
> > edit this file or let a tool edit it (eg: euse).
>
> 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.
>
> Not hard, plus I am now aware of what new things are available.
>
> > If a change, because of a new advanced portage version, to my existing
> > 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 to give the user time to get informed and do the change
> > manually or by using a dedicated tool.
>
> "Gentoo moves pretty fast; if you don't stop and look around once and
> awhile, you could miss out."

--
gentoo-dev@g.o mailing list