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

Proposed handling of generated configuration files (Re: stop the "manage with debconf" madness)

On Sat, Apr 19, 2003 at 02:07:04PM +0100, Matt Ryan wrote:

> Personally I use the ask-about-overwrite question in debconf because the
> last time this thread came up the only sensible solution was put forward
> in the attached email. Now, I'm all for a better solution when it is
> determined what that is, *but* I'm not for a witch hunt based on what was
> seen to be previous best practice.

There was a more recent discussion about the same idea.  A summary of the

- Don't try to parse every program's configuration file format

- Notice that a non-conffile, autogenerated configuration file has been
  modified by the user, and don't lose their changes

- Provide 3-way merge functionality to incorporate changes without losing
  modifications in the common case (I hear this is coming for conffiles as

- Use debconf for prompting

- Have all packages do this using a standard toolset, so that all prompting
  is consistent and well-translated, and certain defaults can be set
  globally (see the threads below for more discussion about this)

I have a clear idea of how I would implement this (and even some code), and
I think that these are all achievable.  The one thing which would be
sacrificed is preconfiguration.

Since autogenerated configuration files, unlike conffiles, require
non-essential tools in order to build them, this work generally needs to be
done in the postinst.  This means that we can't know what the "new"
configuration file looks like until the package is being configured.  And
there's no sense prompting the user ahead of time when they can't see what
the changes look like (Do you want to overwrite your modifications with some
random garbage I can't show you now? [Yes/No]).

Consider xserver-xfree86, whose current debconf setup can use autodetection
data from mdetect and read-edid, but this cannot work unless these packages
are installed when xserver-xfree86's .config script runs.  There is no
dependency relationship which can provide this guarantee (and it doesn't
sound like a very good idea to have one), so I don't see much of a way
around this.  However, I think that with suitable defaults and priority
settings, the above goals might be worth a sacrifice.  Of course, if someone
can think up a way to make this work _correctly_ (in terms of user
experience) with preconfiguration, that would be fabulous.

Prompting about these configuration files in postinst would be no better or
worse than the current conffile mechanism, though as Branden pointed out in
the previous discussion, the conffile prompting could, in theory, be done at
preconfiguration time, since the conffile itself is available in the deb.
Generated configuration files, however, are not.

What do folk think about this tradeoff?  Or is there a way around it?



 - mdz

Reply to: