Re: automating debconf

[Arthur Korn <arthur@korn.ch>]

Craig Sanders schrieb:
> > I'd do it with 'noninteractive' and copying config files around
> > I think ...
> 
> the trouble with noninteractive is that it leaves me no control over
> what happens. i can't afford to just ignore what debconf-enabled
> packages will do to my systems, i need to be able to control it.

Now consider this carefully please:

If you youse debconf with the noninteractive frontend, you can
_forget_about_debconf_. The package will behave just as every
debian package that uses dpkg's conffiles mechanism and installs
a default configuration file at install time. If you want
control at install time, use a interactive frontend or a backend
database, if you don't want to bother about this then stick with
noninteractive and ignore debconf.

I don't think that the pipe method can work reliable and give
you anything that copying/editing config files can't. How would
you know which questions will be asked in which order without
running debconf on a identical machine once before? If you have
to run debconf once anyway you can just as well use the backend
database or copy around the config files and use noninteractive
for further installs. 

> for the purpose of doing remote upgrades and installs, i'd like to
> be able to just ignore debconf...but i can't because i have no way
> of knowing what any particular package is going to do when it gets
> upgraded, and no way of knowing what the defaults are going to be - some
> will blow away my configuration file and regenerate it from the debconf
> backend. that's a bug and a misuse of debconf but it happens, and it's
> likely to happen more often in future as debconf becomes more useful and
> the temptation to use it instead of text-file configuration (i.e. use it
> as a pseudo-registry) increases.

You should concentrate your efforts on getting packages that
abuse debconf in such a way fixed instead of complicating
matters.

> > > it is also necessary - debconf should not destroy useful
> > > functionality (e.g. the ability to install/upgrade a package on a
> > > remote system using ssh and a script).
> >
> > It does not!
> 
> it does. i've even provided evidence of it doing exactly that,
> along with a detailed description of what the problem is and how it
> could/should be fixed.

Hell that's not debconf thats broken packages!! When will you
begin to fix your problem instead of working around it in
obscure ways?!

ciao, 2ri
-- 
"I didn't know it was impossible when I did it."