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

debconf as a registry

Hello list and Joey,

about a year ago, I reported a wishlist bug on debconf (#690390, more
details below).  I received a reply which seemed to say you agree with
me on all points except implementation.  I asked why you didn't agree on
that, since it would make many things better, IMO.  Unfortunately you
didn't reply to that.  (No problem; I suppose you were busy, and I
didn't ping until this e-mail.)

I'm sending this to -devel, because I think it would be useful to have
more opinions.  I'm sure the readership will come up with viewpoints
both of us hadn't considered.

For those who don't want to read the bug log, here's a summary:

Debconf caches answers that users give it, and provides those as
defaults the next time the question is asked.  But almost always, the
answer is also stored in a configuration file.  Which means there are
two places holding the same info.  If they are out of sync, most likely
the admin has edited the config file.  This means that the value in
there should be used, not the cache of debconf.  Packages that use
debconf's cache instead, are rightfully accused of using debconf as a
registry, and should be fixed.

What this means, is that every package which asks debconf questions (and
stores the answers in a configuration file) will need to:

1. Parse the configuration file, if it exists, and set the values as
defaults before asking the questions. (in the config script)
2. Update the values in the configuration file. (in the postinst script)

Currently, many packages only do 2, and that is wrong.

Now I'll quote a piece from the bug log, because I think it's written
clear there:

On Sat, Oct 13, 2012 at 01:27:31PM -0400, Joey Hess wrote:
> Bas Wijnen wrote:
> > The proposed solution is to add functionality to debconf, which can
> > read and edit config files.
> debconf already contains this functionality. It's called a config
> script.

[...] If I understand you correctly, you are saying that each of those
packages should implement parsing code for it in its config script. My
point is that this results in needless code duplication. Therefore I
would like to move this parsing code to debconf, so most packages can
simply use a function call. Packages which have more complex config
files must still implement parsing code for it themselves.

End of the quote.

The most straightforward and non-intrusive solution would be to create a
new package containing this parsing code and let all packages that want
to use it depend on that.  However this doesn't work.  From

> Note that the config script is run before the package is unpacked.  It
> should only use commands that are in essential packages.  The only
> dependency of your package that is guaranteed to be met when its
> config script is run is a dependency (possibly versioned) on debconf
> itself.

Note that this means even a Pre-Depends wouldn't do the trick.  The only
thing that would work, would be to add it as a Build-Depends and mangle
the config script at build time.  It sounds ugly to me, but I suppose it
can be done.  It could even be a debhelper add-on to hide the uglyness.

Would that be a good thing to do?
Are there other things I'm missing?
Is this a non-problem, that doesn't need a solution?


Attachment: signature.asc
Description: Digital signature

Reply to: