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
--
[email protected] mailing list
