* Matthew Gatto <[EMAIL PROTECTED]> [2003-03-11 18:30:19 -0500]: > > 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.
I'll grant you this one. In fact I can see one instance where I wouldn't bother looking at the config file: if the einfo informed me that the changes consisted of adding the paths of package components, I would assume the ebuild knew where it installed them and got the config file correct. > 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. I would never make such an argument. Sorry that it came across that way. My concern is that the "improvements" don't jepordize the integrity of my system. If that requirement is accepted, including giving me the ability to be paranoid when I feel it necessary, I'm all for simplifying things. > > 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. Assuming that the person is replacing the files with inspecting the diffs, yes. However, I always inspect the diffs so there are times an auto-replace would be less safe. > The rare user who would want to keep the old behavior of manually > approving all replacements, should obviously have that available as an > option. So I'm rare, eh? I wonder how much I would fetch at Christy's... <lol> I don't think the maintaner could be talked into removing it anyway so this is a non-issue. > 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. Those would be important to me as well before I would consider using an auto-replace feature. Since I've thought of at least one instance where auto-replace would be useful, maybe adding the option "auto-replace all remaining config files" would be a good compromise. Then the person who doesn't want to see all the diffs could select that the first time etc-update presents him with its menu while someone like me could go through the configs like now and select the option when there are just a few left that are known safe to auto-replace. Probably should even be added as a command line option for someone who is going to auto-replace all the config files. > cheers and to you as well -- Thomas M. Beaudry k8la / ys1ztm [EMAIL PROTECTED] -- [EMAIL PROTECTED] mailing list
