Neil Bothwick wrote: > On Sun, 12 Feb 2006 14:37:41 +0100, Maarten wrote: > > >>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 ?
> Not. What is the default settings change. You may not have edited the > config because the old defaults were what you wanted, but the new > defaults may break your system. Your old config file, with the settings > you needed, has now gone to bit heaven and you are left with a broken > system. Hum, I'll go along in that there _may_ be changes in the default behaviour that a user may not want, but tough luck; the opposite is far _more_ likely: that the new binary can't cope with the old config, and you then also are left with a broken system. Same difference... Is is also very possible that the new binary has different behaviour regardless of config. Emerging world can, and does, change things and I would suggest that if a user doesn't want any surprises he/she shouldn't run emerge world in the first place... But apart from that, I'd even dare suggest that, when emerging a package + its config file changes the default behaviour and that change is not unavoidable (by setting the right options in the new config) that that ebuild is plain broken. There is one exception to that, however: when the change is neccessary from a security standpoint. In that case I'd say it is _good_ that the old config with the insecure setting gets overwritten. Remember, the user _did_not_edit_ the file at any point, so there should be no "expectancy of non-breakage" by an update. If a user explicitly wants to keep the config, what is wrong with him running 'touch' on all configs he wants unchanged? And besides, I never suggested that my new procedure _shouldn't_ make backups of all configs it replaces, just like dispatch-conf can do. In my case, emerge world very often breaks things, no matter if I use the old or the new config. So saying "this may break things" in very rare occasions is a bit like saying "while you're in the air falling down and both your parachutes fail to work, you also get the hiccups". ;-) > Of course, Gentoo is all about choice, so if you want to take that > change, you can set dispatch-conf to do what you want. If you say so... but it is non-obvious. Or if by that you mean I have to make a huge list of CONFIG_PROTECT_MASK files... well, that takes even more time than just running dispatch-conf and be done with it. What I'm looking for is a way to automate things a bit more. Defining a list of what may and what may not be overwritten can be quite tedious, and is by no means automatic. > # Automerge files that the user hasn't modified > # (yes or no) > replace-unmodified=no I _have_ set that setting at "yes" of course, but it works nowhere near useful... even to the point that I figured the setting was broken, or was only a stub for future enhancement... That said, cfg-update sounds exactly like what I need, so... Regards, Maarten -- gentoo-user@gentoo.org mailing list
