<div class="gmail_quote">On Mon, Jan 4, 2010 at 13:23, John McCabe-Dansted <<a href="mailto:gmatht@gmail.com">gmatht@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <div class="im">On Mon, Jan 4, 2010 at 10:47 PM, Soren Hansen <<a href="mailto:soren@ubuntu.com">soren@ubuntu.com</a>> wrote: > If a package upgrade includes a change to a conffile (a configuration > file managed by dpkg) compared to the version installed by the old > version of the package, and you have made changes to said conffile, you > will be prompted about these changes. If, however, something else (e.g. > webmin) has made these changes on your behalf, you will be prompted > about changes you have not made to a conffile you likely have never > heard of. I'm just saying that this is not acceptable, which is a major </div>In principle it seems trivial for webmin etc. to keep a log of what it changes and why, and add hooks for these changes to be automatically reapplied upon update. This would seem vastly better than the current situation where the whole upgrade process stops in the middle to wait for user input if a config file has been changed. It'd be nice if we could just leave an upgrade running overnight and have a fully functional system when we wake up in the morning. It'd also be nice to be able to take the log of all changes made to the system, edit it, and then replay it on another freshly installed system. IMHO all changes should be done by some "automated system", even if it is just a script that does cp ; vi ; diff ; sudo patch </blockquote></div> *IF* every package had a way to separate the *default* configuration values from the *local* changes then things would be MUCH easier. Without this the only way to avoid bothering the user with these prompts would involve calling a "pre-upgrade" script in such a way that Webmin (or any other such "user friendly control panel" system) could actually "revert" the local changes it did, so the package system would simply upgrade the config without a hitch. After the upgrade the user would (perhaps manually) reapply the patches back. But even this doesn't solve all isues. For example, if a default values changes from version to version (as it does frequently) then it may be necessary to "patch the patch" before applying it back! That's part of the problem - each package is different. It's nearly impossible to devise a single standard way to manage configuration changes. -- Carlos Ribeiro Consultoria em Projetos twitter: <a href="http://twitter.com/carribeiro">http://twitter.com/carribeiro</a> blog: <a href="http://rascunhosrotos.blogspot.com">http://rascunhosrotos.blogspot.com</a> mail: <a href="mailto:carribeiro@gmail.com">carribeiro@gmail.com</a>