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

Re: Using XML to handle all configuration files

>>>>> "Nicolás" == Nicolás Lichtmaier <nick@debian.org> writes:

    Nicolás>  I would say that each program would define its own tags,
    Nicolás> so in this example the namespace could be something
    Nicolás> like...  http://www.debian.org/XML/etc/network/interfaces
    Nicolás> ). Similar programs should agree on a vocabulary, as they
    Nicolás> [should] do today with debconf variables.

Agreed. Not sure if we should use www.debian.org (as some of this is
configuration for upstream packages), but I guess this is a good start
for now.

You have shown one possible naming system. I will suggest another:


Where "heimdal-libs" is the name of the package, 0.3d-6 is the *first*
version that uses this format (in case a latter version changes the
format), and "packages.debian.org" clearly shows that this is an
official Debian package.

    Nicolás>  Yes, a program edit the XML form of the config file, and
    Nicolás> the "xmldeconverter" writes the traditional format
    Nicolás> afterwards. Easy frontends can be created by the use of
    Nicolás> xpath, but without forcing debian developers to use xslt:

    Nicolás> conf="$(getconf "/interfaces/iface[@family='inet6']" )"
    Nicolás> test "$conf" && echo do you really want ipv6????  =)

    Nicolás> where getconf is a property getter program like the ones
    Nicolás> used by debconf.

Yes, I didn't think of using XPath before...

What you really need though (I think) is a corresponding setconf
program, too. So a script can extract values from debconf and write
them to the XML file for instance.

    >> Other things could be useful to, eg, changelog describing when
    >> and what changes where made to this config file, etc.
    >> I think some of these features would be very useful, and may
    >> even stronger arguments as to why XML files are required then
    >> what has already been discussed.

    Nicolás>  So.. each package would have a control file (like the
    Nicolás> ones in /var/lib/dpkg/info) describing the current
    Nicolás> conffile format version. This would be the "traditional"
    Nicolás> format, not the XML one. They XML one should not

I am afraid you have lost me here, what is this extra control file
used for?

    Nicolás> change.... hey..!!! here is a big thing::!!! imagine that
    Nicolás> the traditional format changes, so on package
    Nicolás> replacement, the configfile is converted to XML by the
    Nicolás> old package, and converted to "traditional form" by the
    Nicolás> new one.  So we have an automatic migration procedure
    Nicolás> free...!

Agreed. Although this is something that will need to be tested in
practise, too. For instance, it is possible that maintainers will make
mistakes in designing the XML file which mean it has to be redone from
scratch. It should be possible to provide assistance as required to
people involved in designing XML files in order to minimise mistakes

    >> I would almost be willing to argue that packages may edit XML
    >> config files from other packages (currently against debian
    >> policy), because this is much more flexible then anything that
    >> could be specified on the command line for an update
    >> program. Care needs to be taken though, as the XML format could
    >> change... Perhaps a compromise between the two extremes might
    >> be good (eg. update program which takes XML as its input).

    Nicolás>  Besides, with XML, the editions would be something
    Nicolás> cleaner than the current "sed" approach. Editing other
    Nicolás> packages files is probably forbidden in part due to the
    Nicolás> fragility of this method.  Perhaps it should be mandated
    Nicolás> how should programs which modifies other programs file
    Nicolás> should behave. Like prompting to the user or so.

Brian May <bam@debian.org>

Reply to: