* RE: [gentoo-dev] etc-update
@ 2003-03-07 21:13 Martin, Stephen
0 siblings, 0 replies; 5+ messages in thread
From: Martin, Stephen @ 2003-03-07 21:13 UTC (permalink / raw
To: 'gentoo-dev@gentoo.org'
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* RE: [gentoo-dev] etc-update
@ 2003-03-07 21:19 Balaji Srinivasan
2003-03-08 3:57 ` Michael Kohl
0 siblings, 1 reply; 5+ messages in thread
From: Balaji Srinivasan @ 2003-03-07 21:19 UTC (permalink / raw
To: 'Martin, Stephen', 'gentoo-dev@gentoo.org'
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [gentoo-dev] etc-update
2003-03-07 21:19 Balaji Srinivasan
@ 2003-03-08 3:57 ` Michael Kohl
0 siblings, 0 replies; 5+ messages in thread
From: Michael Kohl @ 2003-03-08 3:57 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 764 bytes --]
On Fri, 7 Mar 2003 13:19:33 -0800
Balaji Srinivasan <BSrinivasan@extremenetworks.com> wrote:
> 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.
Some users (me included) use PORTAGE_OVERLAY, PORT_LOGDIR etc.
There are also people who are using alternative programs for fetching
files.
Users of distcc or SMP systems change the MAKEOPTS, some tinke with
features (like userpriv and usersandbox).
"Normal behaviour" is pretty hard to define, especially for a really
versatile distribution like Gentoo.
Michael
--
www.cargal.org
GnuPG-key-ID: 0x90CA09E3
Jabber-ID: citizen428 [at] cargal [dot] org
Registered Linux User #278726
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* [gentoo-dev] etc-update
@ 2003-04-13 9:57 Brian Harring
2003-04-13 16:07 ` Jon Portnoy
0 siblings, 1 reply; 5+ messages in thread
From: Brian Harring @ 2003-04-13 9:57 UTC (permalink / raw
To: gentoo-dev
While I'm on an emailing spree, anyone got any ideas on how to make etc-update
a bit less painful?
It seems like a lot of the times where etc-update requires user intervention
it's fairly minor- case in point, make.conf, when the default/base-layout
make.conf gets updated. It seems like it usually chokes on configured
options, features or gentoo_mirrors as an example.
What if we were to either A) maintain a listing of default conf files (when
modifying/adding a conf file, make.conf again, store it somewhere), or B)
pull the conf from the distfile in some way? The reason I ask is it strikes
me if etc-update where able to compare the old default conf against the
current conf it might be able to create a diff it could use to patch against
the new one. A bit wordy, but basically I'm wondering if we could isolate
the changes a user has made, and attempt to merge those changes into the new
conf file via a diff.
The problem I see with this would be that where (say GENTOO_MIRRORS) gets
updated to some new default setting, the generated diff wouldn't be able to
match against the new conf.
Thoughts?
~harring
bdharring@wisc.edu
--
gentoo-dev@gentoo.org mailing list
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [gentoo-dev] etc-update
2003-04-13 9:57 Brian Harring
@ 2003-04-13 16:07 ` Jon Portnoy
0 siblings, 0 replies; 5+ messages in thread
From: Jon Portnoy @ 2003-04-13 16:07 UTC (permalink / raw
To: Brian Harring; +Cc: gentoo-dev
"Interactively merge changes" does exactly that (uses diff/patch)
On Sun, Apr 13, 2003 at 04:57:20AM -0500, Brian Harring wrote:
> While I'm on an emailing spree, anyone got any ideas on how to make etc-update
> a bit less painful?
> It seems like a lot of the times where etc-update requires user intervention
> it's fairly minor- case in point, make.conf, when the default/base-layout
> make.conf gets updated. It seems like it usually chokes on configured
> options, features or gentoo_mirrors as an example.
>
> What if we were to either A) maintain a listing of default conf files (when
> modifying/adding a conf file, make.conf again, store it somewhere), or B)
> pull the conf from the distfile in some way? The reason I ask is it strikes
> me if etc-update where able to compare the old default conf against the
> current conf it might be able to create a diff it could use to patch against
> the new one. A bit wordy, but basically I'm wondering if we could isolate
> the changes a user has made, and attempt to merge those changes into the new
> conf file via a diff.
> The problem I see with this would be that where (say GENTOO_MIRRORS) gets
> updated to some new default setting, the generated diff wouldn't be able to
> match against the new conf.
> Thoughts?
> ~harring
> bdharring@wisc.edu
>
> --
> gentoo-dev@gentoo.org mailing list
--
Jon Portnoy
avenj/irc.freenode.net
--
gentoo-dev@gentoo.org mailing list
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2003-04-13 16:07 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-03-07 21:13 [gentoo-dev] etc-update Martin, Stephen
-- strict thread matches above, loose matches on Subject: below --
2003-03-07 21:19 Balaji Srinivasan
2003-03-08 3:57 ` Michael Kohl
2003-04-13 9:57 Brian Harring
2003-04-13 16:07 ` Jon Portnoy
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox