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 -- gentoo-user@gentoo.org mailing list
