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:
http://packages.debian.org/heimdal-libs/0.3d-6/krb5.conf
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
made.
>> 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.
Agreed.
--
Brian May <bam@debian.org>
Reply to: