[gentoo-user] How to work with etc-updates.

[gentoo-user] How to work with etc-updates.

[Jerry Turba]

As I understand the process etc-update lists new configuration files 
provided by the program authors. I have tried to define some rules for 
myself to determine how to handle these new files.

1. If I made a change to a file I will never allow the new config file 
to overwrite the old file.

2. If the new config file is a new default file I will accept the new file.

3. I will never change a file that is program code, (I am not a programmer).

Are these rules sane? What kind of problems could I run into doing this? 
What would be some better rules to use? I have tried dispatch-conf but I 
still have to make the same decisions. Am I missing something?

Thanks for any advice.

Jerry
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] How to work with etc-updates.

[Mark Knecht]

On 8/30/05, Jerry Turba <jturba@nethere.com> wrote:
> As I understand the process etc-update lists new configuration files
> provided by the program authors. I have tried to define some rules for
> myself to determine how to handle these new files.
> 
> 1. If I made a change to a file I will never allow the new config file
> to overwrite the old file.

I know one person who operated like this but I didn't agree. I think
that you have to (eventually) do the update. The developers change
things in these files also. If you don't change you don't get the
updates, or things (possibly) don't get activated.

> 
> 2. If the new config file is a new default file I will accept the new file.
> 
> 3. I will never change a file that is program code, (I am not a programmer).
> 
> Are these rules sane? What kind of problems could I run into doing this?
> What would be some better rules to use? I have tried dispatch-conf but I
> still have to make the same decisions. Am I missing something?
> 

My rules are:

1) The update was put there for a reason.

2) If it's a file in /etc/initd then I update it automatically.

3) If it's a file in /etc/conf.d then I update it very carefully.

4) If it's a file in /etc/, /etc/X11, or elsewhere the I update it
very carefully but possibly not right now.

5) Anything else, I go slow. Maybe I look for messages from others on
this list having problems before I do something.

My experience is that rules 2 & 3 account for 80-90% of the updates.

Cheers,
Mark

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] How to work with etc-updates.

[Jerry Turba]

Thanks everyone for your help. I will try using Marks rules and start 
using dispatch-conf to be able to roll back any changes that don't seem 
to work.
Jerry


Mark Knecht wrote:

>On 8/30/05, Jerry Turba <jturba@nethere.com> wrote:
>  
>
>>As I understand the process etc-update lists new configuration files
>>provided by the program authors. I have tried to define some rules for
>>myself to determine how to handle these new files.
>>
>>1. If I made a change to a file I will never allow the new config file
>>to overwrite the old file.
>>    
>>
>
>I know one person who operated like this but I didn't agree. I think
>that you have to (eventually) do the update. The developers change
>things in these files also. If you don't change you don't get the
>updates, or things (possibly) don't get activated.
>
>  
>
>>2. If the new config file is a new default file I will accept the new file.
>>
>>3. I will never change a file that is program code, (I am not a programmer).
>>
>>Are these rules sane? What kind of problems could I run into doing this?
>>What would be some better rules to use? I have tried dispatch-conf but I
>>still have to make the same decisions. Am I missing something?
>>
>>    
>>
>
>My rules are:
>
>1) The update was put there for a reason.
>
>2) If it's a file in /etc/initd then I update it automatically.
>
>3) If it's a file in /etc/conf.d then I update it very carefully.
>
>4) If it's a file in /etc/, /etc/X11, or elsewhere the I update it
>very carefully but possibly not right now.
>
>5) Anything else, I go slow. Maybe I look for messages from others on
>this list having problems before I do something.
>
>My experience is that rules 2 & 3 account for 80-90% of the updates.
>
>Cheers,
>Mark
>
>  
>

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] How to work with etc-updates.

[Mark Knecht]

On 8/31/05, Jerry Turba <jturba@nethere.com> wrote:
> Thanks everyone for your help. I will try using Marks rules and start
> using dispatch-conf to be able to roll back any changes that don't seem
> to work.
> Jerry
> 

Darn, that's scary! OK, if you're gonna follow someone as blind as me
le me expand these a bit so that I can say I really tried...

> 
> Mark Knecht wrote:

> >
> >My rules are:
> >
> >1) The update was put there for a reason.
> >
> >2) If it's a file in /etc/initd then I update it automatically.

This rule is still true. I am not a programmer and will never edit an
init script. For me these are 100% updated ASAP.

> >
> >3) If it's a file in /etc/conf.d then I update it very carefully.

This rule is true but needs some expanding on. We all edit a few
/etc/conf.d files, for hostname, rc for whether to use a tarball or
not, etc. I know the 5 or 6 that I edit. If the etc-update is for one
of those files then I generally go very carefully. Mostly I'll let
etc-update do it's thing, but I look very carefully at all changes,
and then I go back and redo my edit by hand if it's necessary when
etc-update is done.

However, today I did an emerge and etc-update wanted to do something
to /etc/conf.d/spam. Since I know I do not edit that file I just let
it do the update. No problem.

> >
> >4) If it's a file in /etc/, /etc/X11, or elsewhere the I update it
> >very carefully but possibly not right now.

This rule is still true. My experience is that xorg.conf is often more
heavily modified by me so I don't want that getting changed. I will
often make a copy of my current file and then let etc-update do it's
thing and then go back and redo my work by hand again. It's tedious,
and I know that many others would think it strange what I do,  but
seems to be the safest for me.

> >
> >5) Anything else, I go slow. Maybe I look for messages from others on
> >this list having problems before I do something.

Still true unless it looks like a file that I consider system oriented
in which case I just let it happen and hope for the best. Linux is a
tool for me. I don't do system stuff myself so if the devs want it
changed let it change.

> >
> >My experience is that rules 2 & 3 account for 80-90% of the updates.
> >

Hope this helps.

Good luck,
Mark

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] How to work with etc-updates.

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 437 bytes --]

On Wed, 31 Aug 2005 20:16:55 -0700, Mark Knecht wrote:

> > >2) If it's a file in /etc/initd then I update it automatically.
> 
> This rule is still true. I am not a programmer and will never edit an
> init script. For me these are 100% updated ASAP.

Add /etc/init.d to CONFIG_PROTECT_MASK in /etc/make.conf and they'll be
updated even sooner.


-- 
Neil Bothwick

Don't take life too seriously, you won't get out alive.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-user] How to work with etc-updates.

[Boyd Stephen Smith Jr.]

On Thursday 01 September 2005 04:09 am, Neil Bothwick wrote:
> On Wed, 31 Aug 2005 20:16:55 -0700, Mark Knecht wrote:
> > > >2) If it's a file in /etc/initd then I update it automatically.
> >
> > This rule is still true. I am not a programmer and will never edit
> > an init script. For me these are 100% updated ASAP.
>
> Add /etc/init.d to CONFIG_PROTECT_MASK in /etc/make.conf and they'll
> be updated even sooner.

Speaking of, CONFIG_PROTECT_MASK, how can I remove /etc/env.d from it?  
I don't want ebuilds overwriting my environment tweaks that I've added.

-- 
Boyd Stephen Smith Jr.
bss03@volumehost.com
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] How to work with etc-updates.

[Roger Light]

On 30/08/05, Jerry Turba <jturba@nethere.com> wrote:

> As I understand the process etc-update lists new configuration files
> provided by the program authors. I have tried to define some rules for
> myself to determine how to handle these new files.
> 
> 1. If I made a change to a file I will never allow the new config file
> to overwrite the old file.

This isn't really a good idea. There are definitely cases where the
new file will provide important updates that you need. Not updating
the config file could lead to the associated program no longer working
or you missing out on a useful feature.

Using etc-update, select the file you have changed and look at the
differences. You may see that  other than the changes you made, there
are only updates to comments within the file. In this case you can of
course just ignore the update.

If there are real updates and your own update looks as though it is
still valid then use the "Interactively merge original with update"
option. You can then choose which lines to include in the new file.
The left hand side of the diff output is the original file, the right
hand side is the new. So for each line presented, apart from for the
lines that you have modified, input "r" to choose the right hand side
line. For the lines you changed, input "l" to choose your version.

Always verify the resulting file with "Show differences between merged
file and original" before selecting the "Replace YOUR_FILE with merged
file" option.

All just my opinion of course...

Cheers,

Roger

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] How to work with etc-updates.

[Holly Bostick]

Jerry Turba schreef:
> As I understand the process etc-update lists new configuration files
> provided by the program authors. I have tried to define some rules for
> myself to determine how to handle these new files.
> 
> 1. If I made a change to a file I will never allow the new config file
> to overwrite the old file.

I disagree. Certainly there are some 'new' config files that you should
never, ever allow etc-update to overwrite, such as /etc/fstab. However,
if the format of the config file has been changed in the meantime, some
of the settings in the old config file may be invalid, and new, valid
default settings (for areas that you have not changed) will not be added.

This is what the '3' option is for, after the changes have been
displayed: 'Interactively merge update with original'.

I use this in those cases to preserve those settings that I want to
keep, while upgrading the config header, comments, and other settings to
the new defaults.

In those very rare cases where the line ordering has changed so much
that the diff utility would overwrite one or more settings, I accept the
new file, and immediately edit it with nano to change the (usually) one
or two lines that were 'wrongly' diff-ed.

> 
> 2. If the new config file is a new default file I will accept the new file.

Agreed.

> 
> 3. I will never change a file that is program code, (I am not a
> programmer).

Agreed.
> 
> I have tried dispatch-conf but I
> still have to make the same decisions. Am I missing something?

Not really; that would be Gentoo. Decision is not meant to be taken out
of your hands. But the power to choose how your system is configured
carries the responsibility to pay attention to the offered changes and
think about their effects (which means you have to know what their
effects are going to be, which means you have to learn wtf is going on
on your system in the first place).

Holly
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] How to work with etc-updates.

[Eric Crossman]

On Tue, 2005-08-30 at 16:46 +0200, Holly Bostick wrote:
> Jerry Turba schreef:
> > As I understand the process etc-update lists new configuration files
> > provided by the program authors. I have tried to define some rules for
> > myself to determine how to handle these new files.
> > 
> > 1. If I made a change to a file I will never allow the new config file
> > to overwrite the old file.
> 
> I disagree. Certainly there are some 'new' config files that you should
> never, ever allow etc-update to overwrite, such as /etc/fstab. However,
> if the format of the config file has been changed in the meantime, some
> of the settings in the old config file may be invalid, and new, valid
> default settings (for areas that you have not changed) will not be added.
> 
> This is what the '3' option is for, after the changes have been
> displayed: 'Interactively merge update with original'.
> 
> I use this in those cases to preserve those settings that I want to
> keep, while upgrading the config header, comments, and other settings to
> the new defaults.
> 
> In those very rare cases where the line ordering has changed so much
> that the diff utility would overwrite one or more settings, I accept the
> new file, and immediately edit it with nano to change the (usually) one
> or two lines that were 'wrongly' diff-ed.
> 
> > 
> > 2. If the new config file is a new default file I will accept the new file.
> 
> Agreed.
> 
> > 
> > 3. I will never change a file that is program code, (I am not a
> > programmer).
> 
> Agreed.
> > 
> > I have tried dispatch-conf but I
> > still have to make the same decisions. Am I missing something?
> 
> Not really; that would be Gentoo. Decision is not meant to be taken out
> of your hands. But the power to choose how your system is configured
> carries the responsibility to pay attention to the offered changes and
> think about their effects (which means you have to know what their
> effects are going to be, which means you have to learn wtf is going on
> on your system in the first place).
> 
> Holly

While I agree that etc-update is a vast improvement over other package
systems, it would be nice to have a CVS type merge where I only have to
make choices when the "system can't figure it out". It seems like
etc-update (and friends) should be able to take advantage of mtime
metadata and md5 checksums to determine if I've made any modifications
to the default config file. That way an unmodified default config from
version N can just safely be replaced with the new default for version N
+1. Does this functionality already exist with the current etc-update?

Eric C.

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] How to work with etc-updates.

[Tony Davison]

On Tuesday 30 August 2005 17:06, Eric Crossman wrote:
<much snippery>
> While I agree that etc-update is a vast improvement over other
> package systems, it would be nice to have a CVS type merge where I
> only have to make choices when the "system can't figure it out". It
> seems like etc-update (and friends) should be able to take advantage
> of mtime metadata and md5 checksums to determine if I've made any
> modifications to the default config file. That way an unmodified
> default config from version N can just safely be replaced with the
> new default for version N +1. Does this functionality already exist
> with the current etc-update?
>
Check out /etc/dispatch-conf.conf
-- 
Tony Davison
tony.davison2@ntlworld.com
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] How to work with etc-updates.

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 904 bytes --]

On Tue, 30 Aug 2005 12:06:29 -0400, Eric Crossman wrote:

> While I agree that etc-update is a vast improvement over other package
> systems, it would be nice to have a CVS type merge where I only have to
> make choices when the "system can't figure it out". It seems like
> etc-update (and friends) should be able to take advantage of mtime
> metadata and md5 checksums to determine if I've made any modifications
> to the default config file. That way an unmodified default config from
> version N can just safely be replaced with the new default for version N
> +1. Does this functionality already exist with the current etc-update?

It exists as an option with dispatch-conf, as do options to automatically
replace files if the only differences are whitespace and comments.


-- 
Neil Bothwick

Distrust any enterprise that requires new clothes. - Henry David Thoreau
(1817-1862)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-user] How to work with etc-updates.

[Sean Higgins]

On Tuesday 30 August 2005 01:22 pm, Neil Bothwick wrote:
> On Tue, 30 Aug 2005 12:06:29 -0400, Eric Crossman wrote:
> > While I agree that etc-update is a vast improvement over other package
> > systems, it would be nice to have a CVS type merge where I only have to
> > make choices when the "system can't figure it out". It seems like
> > etc-update (and friends) should be able to take advantage of mtime
> > metadata and md5 checksums to determine if I've made any modifications
> > to the default config file. That way an unmodified default config from
> > version N can just safely be replaced with the new default for version N
> > +1. Does this functionality already exist with the current etc-update?
>
> It exists as an option with dispatch-conf, as do options to automatically
> replace files if the only differences are whitespace and comments.

But, it does not automatically do an update if the original file has not 
changed.  That would be a cool feature.  How often are files changed, for 
example in /etc/init.d, but you have not changed that file?  I would love the 
option to automatically update any configuration file that I did not change 
from the original install.

Right on Eric!

                                Sean

-- 
Sean Higgins, sean@systura.com
http://www.systura.com - "Where information becomes knowledge."
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] How to work with etc-updates.

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 865 bytes --]

On Tue, 30 Aug 2005 17:19:40 -0400, Sean Higgins wrote:

> > It exists as an option with dispatch-conf, as do options to
> > automatically replace files if the only differences are whitespace
> > and comments.
> 
> But, it does not automatically do an update if the original file has
> not changed.  That would be a cool feature.  How often are files
> changed, for example in /etc/init.d, but you have not changed that
> file?  I would love the option to automatically update any
> configuration file that I did not change from the original install.

No it does not do it automatically, that would be dangerous, You have to
enable the option first in /etc/dispatch-conf.conf

# Automerge files that the user hasn't modified
# (yes or no)
replace-unmodified=yes


-- 
Neil Bothwick

Guns don't kill people--it's those little pieces of lead.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]