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
smime.p7s
Description: S/MIME cryptographic signature
