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

2005-10-31 Thread 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.
[EMAIL PROTECTED]
-- 
gentoo-user@gentoo.org mailing list



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

2005-09-01 Thread Neil Bothwick
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.


pgpNtnqDyeij9.pgp
Description: PGP signature


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

2005-08-31 Thread Neil Bothwick
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.


pgpDRImQfMrBC.pgp
Description: PGP signature


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

2005-08-31 Thread 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 [EMAIL PROTECTED] 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.

2005-08-31 Thread Mark Knecht
On 8/31/05, Jerry Turba [EMAIL PROTECTED] 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



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

2005-08-30 Thread 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.

2005-08-30 Thread Mark Knecht
On 8/30/05, Jerry Turba [EMAIL PROTECTED] 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.

2005-08-30 Thread Roger Light
On 30/08/05, Jerry Turba [EMAIL PROTECTED] 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.

2005-08-30 Thread 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.

2005-08-30 Thread 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.

2005-08-30 Thread Neil Bothwick
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)


pgp9E5BWrfoFO.pgp
Description: PGP signature


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

2005-08-30 Thread 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, [EMAIL PROTECTED]
http://www.systura.com - Where information becomes knowledge.
-- 
gentoo-user@gentoo.org mailing list