On Thu, Mar 06, 2003 at 04:00:57PM -0500, [EMAIL PROTECTED] wrote: > Still not a good thing. There could be some new option in the config > file that needs setting. Anyway, with the exception of the XFree
True, but that is not relevant to the very reasonable notion that default config files that have not ever been altered should be replaced by the new default configs when that application is upgraded. There are many ways to alert users that a new option needs to be set such as einfo (in ebuilds), without having to the force the user to consider each and every new/changed config file in turn when running etc-update. For example: when an application is newly installed there may be, and often is many options that need to be set, but we rely on einfo colorized/emphasized notification, documentation, and the users own knowledge and intelligence to ensure that the relevant options are set, not by forcing them to consider each config file. > upgrade <groan>, we're not talking about a lot of time reviewing config > files. The longest I've ever spent other than the XFree upgrade was > five minutes. And that was after I had been in the hospital over a > month and a lot of stuff had changed. > > So with the present system, we're looking at 15-20 minutes once or twice > a year for XFree. Add in 5 minutes monthly or 2-3 minutes if you > upgrade more often than monthly (nightly for me). Does not seem like a > hardship to me for the peace of mind of not having any changes made > unknowingly to my system. Because it's only a little bit annoying rather than alot doesn't mean the process can't or shouldn't be improved. > Maybe you can get the maintaner of etc-update to add such a feature. > I'll never use it. Just one screwed up config file will cost me more > time debugging than it looks like I would spend in a year reviewing > updated config files. That's true too, but you're not any more likely to have a screwed up config file by using a "Auto-replace unchanged config files when new versions are installed" feature, than you would if you were not using such a feature, assuming you are paying attention when upgrading. The rare user who would want to keep the old behavior of manually approving all replacements, should obviously have that available as an option. Two important features for me would be the ability for etc-update to keep config file backups from previous upgrades when the feature is used, and also being verbose by default during the process and letting me know what config files are being auto-replaced during the process, so that I can manually inspect replaced config files for important changes. cheers -- [EMAIL PROTECTED] mailing list
