1 |
Re: make.conf, though, what about having portage automatically merge |
2 |
uncommented make.conf settings, or at least the USE and CFLAGS? Given that |
3 |
they're in the file as a way for the user to override settings in |
4 |
make.globals, it doesn't make a lot of sense to me to have them overwritten |
5 |
and commented out every time make.conf is updated. Granted, it's not a huge |
6 |
inconvenience to merge by hand using etc-update, but I groan every time I |
7 |
see make.conf pop up when I know the only thing I need to keep are the USE, |
8 |
CFLAGS and MIRRORS settings. |
9 |
|
10 |
-Steve |
11 |
|
12 |
|
13 |
-----Original Message----- |
14 |
From: Alain Penders [mailto:alain@g.o] |
15 |
Subject: Re: [gentoo-dev] RE: [gentoo-user] etc-update |
16 |
|
17 |
Splitting config files in sections is useless, we can't dictate how other |
18 |
application developers should structure or load configuration files. |
19 |
|
20 |
|
21 |
On Thu, Mar 06, 2003 at 11:31:23AM -0800, Balaji Srinivasan wrote: |
22 |
> One way these conflicts could be reduced is by separating out sections in |
23 |
> config files that will most probably be modified by the user and those |
24 |
which |
25 |
> are not. For example the USE directive and the CFLAGS directive from |
26 |
> make.conf could be moved to a separate file. That way whenever portage |
27 |
> changes, they wouldnt need to update those flags (or even if they did it |
28 |
> would be easy to merge). This is in ofcourse be in addition to having a |
29 |
way |
30 |
> for the user to indicate which files he is interested in and hence those |
31 |
> files should not be auto updated. Also maintaining a history of updates in |
32 |
a |
33 |
> separate directory would also |
34 |
> help. This way in case things do go wrong we still have access to the old |
35 |
> files. |
36 |
> |
37 |
|
38 |
|
39 |
-- |
40 |
gentoo-dev@g.o mailing list |