| 1 |
On Tue, 2003-09-09 at 18:57, William Kenworthy wrote: |
| 2 |
> Please dont suggest splitting make.conf - its a crap idea and we'll end |
| 3 |
> up with a mess like like conf.d (where it is justified, but its still a |
| 4 |
> mess - and an ongoing pain). You get files changing, adds and deletions |
| 5 |
> that happen and you are not aware of the changes. |
| 6 |
|
| 7 |
I was thinking more like devfs.d and devfsd.conf than the way conf.d is |
| 8 |
used. |
| 9 |
|
| 10 |
> For instance, how many people missed the addition of hdparm to conf.d? |
| 11 |
> There have been a number of disastrous events where wholesale changes |
| 12 |
> have occurred when they were not intended: modules.autoconf was |
| 13 |
> particularly bad (I ended up with 3 dead systems), as was the symlink to |
| 14 |
> the php config file from mod_php and php proper. At least if you have |
| 15 |
> one file, you only have one place to look. Plus it makes sense to keep |
| 16 |
> all related information on one file, not piecemeal. |
| 17 |
> |
| 18 |
> What this will mean, is that after every emerge problem, you will have |
| 19 |
> to find and check dozens of files, not one core file. |
| 20 |
|
| 21 |
Actually, it would be a single make.conf which is generated from files |
| 22 |
in make.conf.d. I think it would be pretty easy if it uses the same |
| 23 |
style as devfs.d and devfsd.conf. This would also allow us to maintain |
| 24 |
backwards compatibility with older versions of portage. You can look in |
| 25 |
make.conf (devfsd.conf) to find the problem, and it lists the settings |
| 26 |
as they are in the files, so you can see that the error is in a |
| 27 |
particular file and fix it quickly. |
| 28 |
|
| 29 |
> And think of the newbie, gentoo is becoming very complex to understand. |
| 30 |
|
| 31 |
The main reason is lack of consistency more than complexity. As long as |
| 32 |
everything uses the same interface, it should not be hard to |
| 33 |
understand. You only have to learn one concept and apply it multiple |
| 34 |
times. |
| 35 |
|
| 36 |
> Another point is I run 3 make.conf's on a laptop, and load the one |
| 37 |
> applicable to the site I am at automatically (actually sed the file). I |
| 38 |
> would have to parse a number of files instead of just one. |
| 39 |
|
| 40 |
Yes and no, at least with the way I'm proposing. The make.conf file |
| 41 |
would be generated from the files in make.conf.d at some time. It would |
| 42 |
probably use some function, such as maybe portage-update, to generate |
| 43 |
the make.conf file. You could easily configure it via a /etc |
| 44 |
configuration file, similar to etc-update. I would think it would be |
| 45 |
something we would setup to run at initial boot. |
| 46 |
|
| 47 |
Honestly, I would like to see a simple curses-based portage-config |
| 48 |
program which allows you to change the settings used in make.conf. This |
| 49 |
would solve the problems of documentation completely, as we could move |
| 50 |
any hand-holding to the application and take them out of the file |
| 51 |
itself. |
| 52 |
|
| 53 |
> I think perhaps make.conf would be better named emerge.environment or |
| 54 |
> gentoo.environment to underscore its function and importance! |
| 55 |
|
| 56 |
Except make.conf really *isn't* that important. It only needs to |
| 57 |
exist. The purpose of make.conf is to override the defaults. The |
| 58 |
make.globals file would be a better candidate for getting a name change. |
| 59 |
|
| 60 |
-- |
| 61 |
Chris Gianelloni |
| 62 |
Developer, Gentoo Linux |
| 63 |
Games Team |
| 64 |
|
| 65 |
Is your power animal a penguin? |
Archives