| 1 |
On Sunday 07 September 2003 03:08, Martin Schlemmer wrote: |
| 2 |
> Come on guys, think what is best for the *distro* (meaning, |
| 3 |
> what will work best for the other 90% of users, |
| 4 |
|
| 5 |
From my point of view the best for the 90% of users in this case (make.conf) |
| 6 |
would be: |
| 7 |
1. a very precise documentation with examples about the user settable things |
| 8 |
for make.conf thats accessable via a standard command, like man make.conf or |
| 9 |
info make.conf |
| 10 |
|
| 11 |
2. a clean, easy to read configuration file without mess and things the user |
| 12 |
doesnt care about so it is easy for the user (even easier for tools) to |
| 13 |
change exactly the setting the user wants to change because it is easier to |
| 14 |
identify the place where the change must happen and easier to identify the |
| 15 |
values that already are there. |
| 16 |
|
| 17 |
You may try this yourself: |
| 18 |
nano -w make.conf as it gets installed |
| 19 |
|
| 20 |
and |
| 21 |
nano -w make.conf with just the settings you actually use, everything else |
| 22 |
thrown out. |
| 23 |
|
| 24 |
Which one is easier to modify? |
| 25 |
Especially try to change a FEATURE setting. Or even better, let a new gentoo |
| 26 |
user try to change a FEATURE setting. |
| 27 |
|
| 28 |
If the user is not sure about the variables/values to put there the user may |
| 29 |
at anytime suspend nano or open another terminal or use another virtual |
| 30 |
console and execute man make.conf |
| 31 |
|
| 32 |
most users probably use just 4 or 5 settings: |
| 33 |
use flags |
| 34 |
c(xx) flags |
| 35 |
sync |
| 36 |
mirrors |
| 37 |
features |
| 38 |
|
| 39 |
the rest is for the majority of users just useless in make.conf. So my |
| 40 |
expirience (and assumption). |
| 41 |
|
| 42 |
|
| 43 |
So i strongly support: |
| 44 |
On Saturday 06 September 2003 23:48, Steven Elling wrote: |
| 45 |
> Requiring portage updates to make.conf at all has always bugged me. The |
| 46 |
> file is meant to contain custom settings for portage and to append to or |
| 47 |
> override variables in make.globals and the defaults. It should not hold |
| 48 |
> all the documentation for make.conf. It should not hold all the |
| 49 |
> defaults... that's what make.globals and the defaults are for. |
| 50 |
> |
| 51 |
> Why is all the documentation on make.conf in make.conf anyway? Shouldn't |
| 52 |
> it be in make.globals or better yet the man page? |
| 53 |
> |
| 54 |
> make.conf is used for system customization and, as such, portage should |
| 55 |
> leave it alone. When portage is installed on the drive for the first time |
| 56 |
> it should not create make.conf. Portage should leave it up to the |
| 57 |
> admin/user of the box to create the file. |
| 58 |
Thats sound like a clean solution to me. Thats the way it should be. |
| 59 |
|
| 60 |
I refuse to update my customised and over the time grown settings in |
| 61 |
/etc/make.conf with /etc/make.conf with comments for things i never intend to |
| 62 |
use. That doesnt make any sense to me to put such useless comments with |
| 63 |
documentation that has to be in the man page anyway in a file thats so |
| 64 |
important for my system. |
| 65 |
I refuse to let anything automaticly update this file. |
| 66 |
I refuse to touch this file until there is a strong need to edit it because i |
| 67 |
want a feature/useflag or whatever. So then, and only then, i edit this file |
| 68 |
or let a tool edit it (eg: euse). |
| 69 |
|
| 70 |
If a change, because of a new advanced portage version, to my existing |
| 71 |
settings is needed, this change should be delayed as other software does it: |
| 72 |
mark the old thing as deprecated and warn the user for some time|versions to |
| 73 |
give the user time to get informed and do the change manually or by using a |
| 74 |
dedicated tool. |
| 75 |
|
| 76 |
Jan |
| 77 |
|
| 78 |
|
| 79 |
-- |
| 80 |
gentoo-dev@g.o mailing list |
Archives