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 [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]