TurnKey Linux's take on Ubuntu appliance development: KISS

[Carlos Ribeiro]

On Mon, Jan 4, 2010 at 13:23, John McCabe-Dansted <gmatht at gmail.com> wrote:

> On Mon, Jan 4, 2010 at 10:47 PM, Soren Hansen <soren at ubuntu.com> 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
>
> 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
>
>
*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: http://twitter.com/carribeiro
blog: http://rascunhosrotos.blogspot.com
mail: carribeiro at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20100104/f1104925/attachment.htm