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

Bug#213266: cdebconf-udeb: debconf-dumpdb to not work



On Mon, Sep 29, 2003 at 07:06:16PM +0200, Petter Reinholdtsen wrote:
> Package: cdebconf-udeb
> Version: 0.45
> 
> When trying to use debconf-dumpdb to extract the current debconf
> values from the database, nothing is printed:
> 
>   ~ # debconf-dumpdb configdb
>   ~ #
> 
> This should produce a list of debconf template names, types and
> values, but nothing appear.

rfc822db does not implement the iterate() methods for templates and
questions. Unfortunately this turns out to be painful to implement,
which I imagine is why it wasn't done to start with.

The rfc822db driver uses the tsearch() family of functions to store its
database. The only iterator function in this family is twalk(). This has
the following deficiencies:

  * The only primitive operation is calling twalk() once to iterate over
    all elements at once, calling a user-supplied function at each step.
    The iterate() interface expects to be able to iterate over one
    element at a time.

  * Although the obvious fallback solution is to accept memory
    inefficiency, store all the elements at once into a list, and feed
    them back one at a time through iterate(), the user function
    supplied to twalk() does not accept a private data argument, so the
    only way to do this would be by using a global variable. This would
    make the code thread-unsafe, and while that may not matter here it
    makes me very uncomfortable in general. Plus, as mentioned, this
    approach is a memory hog on large databases.

One option would be to deprecate iterate() and introduce iterateall(),
which would behave rather like twalk(). However, I'm not sure that this
is a feasible interface given twalk()'s lack of a private data argument.

The other, substantially more invasive, option I see is to get rid of
the whole tsearch() family from rfc822db altogether and use something
with a better iteration interface ...

Cheers,

-- 
Colin Watson                                       [cjwatson@debian.org]



Reply to: