Re: [gentoo-user] Handling of config updates, RFC

[Rumen Yotov]

On Sun, 2006-02-12 at 14:37 +0100, Maarten wrote:
> Hi
>
> I have not been impressed by the handling of configfiles (updating them)
> by neither etc-update nor dispatch-conf, so I pondered on an
> alternative. Not an alternative to those packages, but some extra help,
> possibly integrated into one of those tools.  Please bear with me...
>
> What tickles me the most about the current process is that one sometimes
> gets huge lists of updated files by updating a single package. A package
> which may have never been used, or at least configured, by the user.
> For instance, updating webmin, or snort, yields many many ._cfg files an
> average user knows little about, and does not care about since he never
> tweaked them. In other words, they are in their distibution-default
> state, never edited.  It stands to reason everyone would want all those
> files overwritten by the new ones, is it not ?  Well, neither tool does
> that now. The user is left with two options to handle the task:
> 1) Pick out all non-trivial files in a massive list of over 150 files,
> merge those, and after due consideration have dispatch-conf do all the
> remaining files automatically. (I suspect this is what most people do)
> 2) Go through all the files step by step and choose either overwrite or
> skip as fast as possible, and re-run the tool on the remaining files,
> and this time carefully decide what to do with it, overwrite, shred, or
> merge.
> Well, neither is comfortable. Especially since 'trivial merges' like
> CVS- or revision info are advertized as being dealt with, but in reality
> are often not. I cannot tell you how many 'changes' I get confronted
> with are just trivial changes (like added commentary, and so on)
>
>
> I propose to add an additional mechanism to 'see' whether a file was
> actively changed during the lifetime of the machine, by a very simple
> and dumb means, but nevertheless a very effective one.
> This would work like this:  upon extraction of the stage tarball (or at
> least very very early in the install process) one should set all the
> dates of all the potential configfiles to a set date in the (distant)
> past. Let's say, feb 29 1988.  Only thereafter, we start configuring the
> system, editing fstab, hostname, etc.
>
> Now when we run dispatch-conf, it will first check the date of the file
> that corresponds with a ._cfg file.  If that file has that magic date,
> overwrite it by the new file, and (this is important) re-set the date of
> that new file to that old magic date. The user thus needn't be bothered
> by numerous files he didn't touch, and a very significant time-saving is
> realized for everyone.
>
> If I'm not mistaken, other distributions have had solutions like this
> for ages. For instance, SuSE's YaST had/has a way to see if a user
> touched the configfile, and refuses to touch it if it found out the user
> had changed it manually. (Not a very succesful strategy for people who
> routinely did edit the files, but considering all that, it was still not
> bad.
>
> ...What do you think ?  Has this idea been suggested before ?
> Wouldn't this make the updating a much less painful process ?
> What, if any, would be possible pitfalls using this approach ?
>
> Thank you for your time reading this,
>
> Maarten v d Berg
>
Hi,
Check "cfg-update" it's in portage, and i think it the better.
i'm using it together with "dispatch-conf" but think if switching
completely to 'cfg-update' (or mostly at least).
Check the forums for additional info (features, history etc.)
HTH.Rumen