1 |
I second the groan...make.conf gets update pretty much everytime portage |
2 |
gets updated. New features are always added...Most people dont even touch |
3 |
those lines they leave it to be the defaults. The only lines i modified were |
4 |
the USE, CFLAGS and MIRRORS. Looks like that is the normal behaviour. Now |
5 |
making a change for the better for the majority of the users is better than |
6 |
no change. |
7 |
Balaji |
8 |
|
9 |
-----Original Message----- |
10 |
From: Martin, Stephen [mailto:stephen.martin@××××××××.com] |
11 |
Sent: Friday, March 07, 2003 1:14 PM |
12 |
To: 'gentoo-dev@g.o' |
13 |
Subject: RE: [gentoo-dev] etc-update |
14 |
|
15 |
|
16 |
Re: make.conf, though, what about having portage automatically merge |
17 |
uncommented make.conf settings, or at least the USE and CFLAGS? Given that |
18 |
they're in the file as a way for the user to override settings in |
19 |
make.globals, it doesn't make a lot of sense to me to have them overwritten |
20 |
and commented out every time make.conf is updated. Granted, it's not a huge |
21 |
inconvenience to merge by hand using etc-update, but I groan every time I |
22 |
see make.conf pop up when I know the only thing I need to keep are the USE, |
23 |
CFLAGS and MIRRORS settings. |
24 |
|
25 |
-Steve |
26 |
|
27 |
|
28 |
-----Original Message----- |
29 |
From: Alain Penders [mailto:alain@g.o] |
30 |
Subject: Re: [gentoo-dev] RE: [gentoo-user] etc-update |
31 |
|
32 |
Splitting config files in sections is useless, we can't dictate how other |
33 |
application developers should structure or load configuration files. |
34 |
|
35 |
|
36 |
On Thu, Mar 06, 2003 at 11:31:23AM -0800, Balaji Srinivasan wrote: |
37 |
> One way these conflicts could be reduced is by separating out sections in |
38 |
> config files that will most probably be modified by the user and those |
39 |
which |
40 |
> are not. For example the USE directive and the CFLAGS directive from |
41 |
> make.conf could be moved to a separate file. That way whenever portage |
42 |
> changes, they wouldnt need to update those flags (or even if they did it |
43 |
> would be easy to merge). This is in ofcourse be in addition to having a |
44 |
way |
45 |
> for the user to indicate which files he is interested in and hence those |
46 |
> files should not be auto updated. Also maintaining a history of updates in |
47 |
a |
48 |
> separate directory would also |
49 |
> help. This way in case things do go wrong we still have access to the old |
50 |
> files. |
51 |
> |
52 |
|
53 |
|
54 |
-- |
55 |
gentoo-dev@g.o mailing list |
56 |
|
57 |
-- |
58 |
gentoo-dev@g.o mailing list |