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

Re: debconf as a registry

On Fri, Oct 17, 2014 at 12:37:27PM +0800, Thomas Goirand wrote:
> On 10/17/2014 04:34 AM, Bas Wijnen wrote:
> > So debconf needs to read configuration files, but it doesn't know how to
> > parse them.  So it does the only thing it can: it uses its cache.  Which
> > means that each and every package that uses debconf must make sure that
> > they read the configuration files and update debconf's cache _before_
> > running debconf.  And most of them don't do that.
> Could you name a few package for which this is the case? Has bugs been
> opened for them?

I have not reported any bugs, because there is no solution that I
consider acceptable yet.  Any package with a config script that does not
include db_set and that writes the result of db_get to a config file (in
postinst) is broken.  But, as I found, strictly speaking they are not
always violating policy.

Getting random packages from apt-cache rdepends debconf shows:

- several packages that use debconf for questions that are only about
  actions that don't need to be (and aren't) stored in config files.
- cxref uses ucf in postinst.  This doesn't violate policy, but does (in
  case of local changes) give the wrong default in the debconf question,
  and an annoying "do you want to overwrite local changes?" after
  answering the question.  If the default would have been correct, there
  would have been no need for that.
- esmtp starts by asking if you want to overwrite your config and
  refuses to be configured by debconf if you don't.  Also
  policy-compliant, but very unfriendly to users.
- dict does it right.  This costs it more than 20 lines of code in the
  config script.
- dvi2ps does something I don't understand...  It asks questions but
  never runs db_get.  Presumably it pre-seeds some other package?
- ibam depends on debconf but doesn't seem to ask any questions; it
  doesn't even have a config or postinst script.
- gpm does it right, in surprisingly few lines.
- grr does it wrong.

This tiny investigation shows that most of the packages that handle
configuration files are either doing it in a way that is not
user-friendly, or that uses significant code in the config script.  Both
of those cases would benefit from taking that code out of the source (if
it was there) and replacing it with an include statement.

> > The above problems are solved by my plan to create a "static script
> > library", which is included in config scripts at package build time.
> > This library would define functions for parsing common config file
> > formats, and can be included in config scripts with a line similar to
> > ##DEBHELPER##.  This has the benefit of solving the problem, without
> > causing the problem of adding lots of duplicate code to the soures.
> Then such a library *must* be marked as essential, and installed by
> default, otherwise it would break the install workflow.

No; it's a _static_ library.  It is included in the config script at
package build time.  This means every binary package using it will have
a copy of the code in its maintainerscript.  But the source packages do
not.  A change in the library requires a rebuild of all the packages for
the change to take effect.  That's not ideal, but better than marking it
as essential, or making it part of debconf (which would also work, but
requires Joey Hess to accept it, and so far he refuses to even
acknowledge that there is a problem; even if he would, I find making it
a separate package a more elegant solution).

> > Oh yes, and I have some code ready for feedback.  I haven't written the
> > script libraries yet (and I want others to write some of them), but I
> > have written the debhelper module for using them.  I have set up a
> > mini-dinstall repository where you can get the binary and source
> > packages:
> > deb [arch=all,amd64] http://wijnen.dtdns.net/archive unstable main
> > deb-src http://wijnen.dtdns.net/archive unstable main
> > (Please ignore problems with the keys; I'm still getting it to work
> > right.)
> > 
> > The code is derived from dh-autoreconf and it is the first ever perl
> > program I wrote.  So please don't insult me, but also don't hold back
> > when you see things that need to be improved. :-)
> Ok, you have a repository. But which package should we look into?

Oops, sorry and thanks for the reminder.  It's dh-parseconfig:

> As for parsing files, I don't think using perl is a great idea.

The perl script only pastes the file into the config script.  The actual
parsing is done by a script in the language that config is written in.
That means there must be an implementation for every language (/bin/sh
being the most important) and every common file type (ini and csv
probably being the most important).

Note that none of those parsing libraries have been written yet.  I'll
probably take some code from pioneers as a starting point.

I intend most libraries to be included in the dh-parseconfig source, but
it is set up in a way that allows other packages to add libraries as

> Such configuration files sometimes may be huge. But anyway. I have a
> list of features that such a library would need to do for .ini files.

I don't have a bug tracker yet, but I can upload this to unstable if
people don't complain too much about the code. ;-)  Then the bts can be
used for feature requests (and bugs of course).

> This would include not only reading and writing to .ini files, but
> also allow maintenance of them, like for example moving a directive
> from one section to another (when this happens upstream).

The library is meant to make common operations easy.  If a package has
special needs, it must still implement its parsing by itself.  I think
this is on the edge of useful enough for many and too specialist.
Perhaps it would be possible to implement it not entirely in, but with
help of the library.  For example, if there are functions for "read
value from section", "delete value from section" and "write value to
section", it's only one if-statement (use value from new section if
present, otherwise from old section; writing doesn't suffer because you
wouldn't write to the old section anyway, you can just delete the old

Thanks for you feedback,

Attachment: signature.asc
Description: Digital signature

Reply to: