Re: use and abuse of debconf

[Brian May <bam@debian.org>]

>>>>> "Luca" == Luca De Vitis <devitis@students.cs.unibo.it> writes:

    Luca> What about a template system? neither XML nor SGML.  Like
    Luca> most complex and large www application do.  With this, you
    Luca> don't need to spcify any type of configuration file format,
    Luca> simple implementation, no file trasformation needed.

    Luca> We may have a single lib that work with any configutration
    Luca> file... may be an extension for debconf that uses the
    Luca> existing template lib.

I was thinking about that too, but it can only work for extremely
simple stuff.

For example, consider trying to write a automatic debconf front end
for /etc/network/interfaces, where multiple entries exist (sidenote:
does debconf support this?). Do you think a template system can cope
with this? Then have a look at the Kerberos configuration files:

[libdefaults]
default_realm=CHOCBIT.ORG.AU
        clockskew = 300
        v4_instance_resolve = false
        v4_name_convert = {
                host = {
                        rcmd = host
                        ftp = ftp
                }
                plain = {
                        something = something-else
                }
        }
        encrypt = yes
        
[realms]
       CHOCBIT.ORG.AU = {
               kdc = kerberos.chocbit.org.au
               admin_server = kerberos.chocbit.org.au
               default_domain = chocbit.org.au

       }


Now, try adding, deleting, or modifying realms from this file without
messing around with any settings/comments that the user has made, with
a template based system...

One way around this problem would be to convert a source file into
the destination file, for instance:

eth0,address,netmask,gateway
eth1,address,netmask,gateway

but this gets silly - essentially all you are doing is reinventing the
work that has already been done into designing the
/etc/network/interfaces file, with big loss of functionality, and no
real gain.

    Luca> XML would be a solution too, but it is more complicated to
    Luca> implement, not necesary for ststem application
    Luca> configuration: too mutch work by now IMHO. 

Another way would be to design the source file using XML, with all the
detail that is required to produce the destination file.

So, for instance, you would have:
/etc/network/interface.xml

which the user edits and scripts, run as normal. The user runs a conversion
program (perhaps XSLT based) which outputs
/etc/network/interface

Alternatively, a future version of the program may read the
XML file directly, without the need for this intermediate step.


I think there is one big problem (one that I would accept, but others
may not): users would have to become accustomed to editing the XML
file each time, and not the final destination file, and then run some
conversion program (perhaps XSL based) to output the destination file.

Still more and more packages seem to be using templates in some
way or another, and this is already required.

I think using XML is a more consistent approach, as all programs could
follow a similar path (some standard is required here), and I would
consider this a good solution. It means that any program that alters
the configuration file only needs to know the XML format (eg. postinst
script, XML editor, etc). At the same time, existing tools (eg text
editors) will work fine, as XML is text format.

There is a another issue too, IMHO, a debconf one : 1. user modifies
setting "a" in XML file. 2. user (at a latter date) runs
dpkg-reconfigure to change setting "b". 3. postinst scripts, as a side
affect, resets setting "a" back to the original value.
-- 
Brian May <bam@debian.org>