cdebconf plans
I've been getting some inquiries about what the plans are for cdebconf
moving forward. I thought I'd write down a few things I have in mind,
with the hope that other people can help contribute :-)
The goal here is that we can continue to use cdebconf as a small(er)
(size-wise) implementation of the debconf protocol for debian-installer;
at the same time, cdebconf will be a full-implementation of the debconf
spec that will allow you to use cdebconf as a complete replacement of
the perl implementation of debconf if you so desire.
Towards these objectives, I have commited some changes over the last few
days to address some of the main differences that remain between debconf
and cdebconf. Since the last significant changes were committed to
cdebconf several months ago, Joey has made some significant enhancements
to debconf and cdebconf was lagging behind. The main changes I have made
after talking to Joey at OLS was to separate out the concept of a
"template" database vs a "config" database (cdebconf calls the latter a
"question" database). These used to be a single database entity in
cdebconf. Just as in perl-debconf, there is a configuration file that
allows you to choose where the template/question databases are stored,
and which driver is used to store the template/config data.
The second major change I am working on is to introduce the idea of
"instances" in cdebconf. By this I mean that (as in perl-debconf) you
can have multiple databases (or frontends, for that matter) defined for
use, and these can be "stacked" together to form a database chain. For
example, in the default perl-debconf config, the configuration database
is split into a password database which is stored in a read-only file,
whereas the rest of the data is globally readable. To do this in
cdebconf, you would instantiate two instances with the rfc822db driver
(originally written by Tollef Fog Heen) which defines the database file
locations, etc. Then you can define a third instance using a stack
module (to be written) that links them together. If this is not clear,
you may wish to consult either the perl-debconf documentation on how
the Stack module works.
The third area I plan to work on is to improve the documentation for
cdebconf, both in terms of internal code documentation and documentation
of the public APIs that module developers can use to develop new
frontend/database modules. Some of this work was started by Moshe Zadka
already. What I am considering to do is to use doxygen to have in-code
comments that can be processed to give an easily-accessible API
documentation.
Last but not least, Tollef has done some i18nization work on cdebconf.
Right now the mechanism is not very clean; we are working out ways to
improve i18n support in cdebconf.
In parallel, Joey and I will be working on trying to clarify some
items that have become a de-facto standard in how debconf works based on
Joey's implementation, but are not specified formally in the official
specification.
It is my hope that cdebconf will continue to support the small size
footprint required for d-i, but at the same time be suitable as a
full-fledged implementation of the debconf-spec that can be used on
typical Debian installations. Most of the enhancements will happen in
loadable modules (e.g. ldap backends, etc). At the same time I would
like to make sure whatever we do is compatible with Joey's debconf
implementation.
So, in short, volunteers are sought to help write documentation,
loadable frontend and database modules, and of course help test
cdebconf. One of the things Joey and I discussed was the need to come up
with a testsuite that can be used to verify compliance with the
debconf-spec. This will be an interesting and independent project
someone can work on (hint hint) :-)
Comments, criticisms, patches, feature suggestions, etc are always
appreciated. Especially patches!
randolph
--
To UNSUBSCRIBE, email to debian-boot-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: