[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: debconf vs. the sysadmin

The debconf list (config@kitenet.net) cc'ed.

> On Wed, Aug 02, 2000 at 07:34:06PM -0500, Steve Greenland wrote:
> > We need to come up with some way to deal with this issue, or admit
> > that debconf is only useful and should only be used on initial package
> > install.

Well, all we really expect from postinsts is to configure the package
so it's usable initially: if it turns out we can use dpkg-reconfigure
or something beyond an initial install, then that's a definite win,
but it's not really a requirement.

The way I tend to think about this is in comparison to wizards and
properties dialogues under MS Windows. You use a wizard to guide you
through initial configuration until it works, but when you want to change
it to something else, you start messing with the detailed properties
dialogue boxes, or hunting through menus. Similarly, you use debconf
to walk you through an initial setup, but if you want to change your
settings later, you drop into /etc, and hunt around for the appropriate
thing to change.

So, in many cases, I think expecting dpkg-reconfigure to be able to
just politely change a single parameter hidden away in a config file
somewhere may be unreasonable. OTOH, expecting dpkg-reconfigure to be
able to let you get rid of all your existing configuration for a package,
and start again completely from scratch after you've made a huge mess of
things, is probably plausible.

I'm not sure that debconf can really do either of these well atm.

On Thu, Aug 03, 2000 at 08:13:57AM +0100, Mark Brown wrote:
> One thing you can try to do is to have the debconf config script try to 
> set itself up with the values in the configuration file and only update 
> the bits of the configuration file it understands.  This is revolting, 
> very hard for many kinds of configuration file and error-prone but it
> should generally do what the user expects until we start getting multiple
> debconf databases.

An idea (and probably a bad one, considering my track record on debconf
this week...) might be to allow .config's to say:

	CAPB overwrite
		-- corresponding postinst will erase all the old config
		   information and start again from scratch if the
		   internal/overwrite (?) pseudo-question is set to true

		   frontends that support this capability could just add
		   a little checkbox somewhere, frontends that don't
		   could be worked around by having debconf make up
		   a pseudo-question that gets asked

	CAPB autoanswer
		-- .config file can update the debconf database based on the
		   information in /etc

		   frontends supporting this can add a little [autoanswer]
		   button somewhere, similarly, perhaps, and send a new
		   command to the conffile to actually do this updating when
		   the button is clicked


Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.

  ``We reject: kings, presidents, and voting.
                 We believe in: rough consensus and working code.''
                                      -- Dave Clark

Attachment: pgpUj4MdxxEMi.pgp
Description: PGP signature

Reply to: