RE: [gentoo-dev] etc-update

[Balaji Srinivasan <BSrinivasan@extremenetworks.com>]

I second the groan...make.conf gets update pretty much everytime portage
gets updated. New features are always added...Most people dont even touch
those lines they leave it to be the defaults. The only lines i modified were
the USE, CFLAGS and MIRRORS. Looks like that is the normal behaviour. Now
making a change for the better for the majority of the users is better than
no change.
Balaji

-----Original Message-----
From: Martin, Stephen [mailto:stephen.martin@veridian.com]
Sent: Friday, March 07, 2003 1:14 PM
To: 'gentoo-dev@gentoo.org'
Subject: RE: [gentoo-dev] etc-update


Re: make.conf, though, what about having portage automatically merge
uncommented make.conf settings, or at least the USE and CFLAGS?  Given that
they're in the file as a way for the user to override settings in
make.globals, it doesn't make a lot of sense to me to have them overwritten
and commented out every time make.conf is updated.  Granted, it's not a huge
inconvenience to merge by hand using etc-update, but I groan every time I
see make.conf pop up when I know the only thing I need to keep are the USE,
CFLAGS and MIRRORS settings.

-Steve


-----Original Message-----
From: Alain Penders [mailto:alain@gentoo.org] 
Subject: Re: [gentoo-dev] RE: [gentoo-user] etc-update

Splitting config files in sections is useless, we can't dictate how other 
application developers should structure or load configuration files.


On Thu, Mar 06, 2003 at 11:31:23AM -0800, Balaji Srinivasan wrote:
> One way these conflicts could be reduced is by separating out sections in
> config files that will most probably be modified by the user and those
which
> are not. For example the USE directive and the CFLAGS directive from
> make.conf could be moved to a separate file. That way whenever portage
> changes, they wouldnt need to update those flags (or even if they did it
> would be easy to merge). This is in ofcourse be in addition to having a
way
> for the user to indicate which files he is interested in and hence those
> files should not be auto updated. Also maintaining a history of updates in
a
> separate directory would also
> help. This way in case things do go wrong we still have access to the old
> files.
> 


--
gentoo-dev@gentoo.org mailing list

--
gentoo-dev@gentoo.org mailing list