[gentoo-portage-dev] Re: How to prevent dispatch-conf from reverting valid changes

[Duncan]

Pacho Ramos posted on Wed, 01 Aug 2012 12:19:20 +0200 as excerpted:

> On every openrc update I get dispatch-conf wanting to revert all my
> changes in /etc/conf.d files, like KEYMAP, clock...
>
> Is there any way to prevent it from doing that?
>
> Thanks a lot for the info

Interesting.  I use etc-update here, and at least it (working with 
portage) has a feature such that it takes the hash of the package's config 
file, and as long as that doesn't change, it won't bother you again.

Of course if there's a change in the package's config file, it simply 
diffs the files, thus returning hits for parts of the files that haven't 
changed since the last time if they differ, because some other chunk of 
the file is new (say one entirely new option in a file of dozens, the 
rest of which haven't changed).

Between that and the auto-merge-trivial-changes (which would appear to be 
comments in most cases) option, I don't get bothered /too/ often, tho it 
/would/ be nice if it could check individual sections within the file, 
spotting when they haven't changed, so it'd only bother me about the new 
option, not the dozen old options I've already customized.


Another technique that I find helps with some files that I've changed a 
lot, is to put all my changes (save for commenting the defaults where 
necessary, if later changes won't override but instead accumulate) in a 
section at the end.  That way, the main config is identical to the 
unchanged package config, so any changes to it immediately leap out, and 
I can take those changes to the boilerplate section, then edit the file 
afterward, making the corresponding changes to my custom section.

That tends to work pretty well, since I take all the changes upto the 
point where it switches to my custom config, then I refuse the change 
deleting it, and edit the file to make my custom changes based on the 
boilerplate changes just called to my attention.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman