New repository configuration ponderings

Panu Matilainen pmatilai at laiskiainen.org
Tue May 30 08:21:17 PDT 2006


On Tue, 2006-05-30 at 11:37 +0200, Ralf Corsepius wrote:
> On Tue, 2006-05-30 at 00:13 -0700, Panu Matilainen wrote:
> > On Tue, 30 May 2006, Ralf Corsepius wrote:
> > 
> > > On Sun, 2006-05-28 at 20:47 +0300, Panu Matilainen wrote:
> > >> On Sun, 2006-05-28 at 19:31 +0200, Ralf Corsepius wrote:
> > >>> On Sun, 2006-05-28 at 20:17 +0300, Panu Matilainen wrote:
> > >>>> On Sun, 2006-05-28 at 18:20 +0200, Ralf Corsepius wrote:
> > >>>>> On Sun, 2006-05-28 at 17:33 +0300, Panu Matilainen wrote:
> > >>>>>> I've been thinking about improving the repository configuration and
> > >>>>>> related things for a while now. Just yesterday I realized we could
> > >>>>>> easily use the existing main configuration system for this, instead of
> > >>>>>> inventing yet-another-file-format and parser for it.
> > >>>>>
> > >>>>> Well, nice proposal, but ...
> > >>>>>
> > >>>>> ... wouldn't an xml config file format be more suitable?
> > >>>>
> > >>>> I *hate* XML configuration files from user POV.
> > >>>
> > >>>
> > >>> If xml is suitable for something, then it's parsing config files.
> > >>>
> > >>> It avoids all the kind of semifunctional implementation nonsense apt's
> > >>> and yum's config currently carries around, and would dramatically
> > >>> simplify the syntax and a parser's implementation.
> > >>
> > >> Note the "user POV" in my comment above.
> > > Pardon, complete rubbish, IMO.
> > >
> > > I don't see any substantially difference between
> > > <apt>
> > >  <cachedir>cache/fedora/</cachedir>
> > > </apt>
> > >
> > > and
> > >
> > > Apt {
> > >  Cache-dir { cache/fedora }
> > > }
> > 
> > Yeah, I know it's not that big a difference, but XML still gives me the 
> > creeps when encountered in a human editable file.
> 
> Why? Your favorite editor doesn't have an xml-syntax-highlighting mode
> but it has an apt.conf-syntax highlighting mode?

I don't need syntax highlighting to make sense out of apt.conf. My
bigger gripe with XML as human written language is the amount of extra
crap you have to type - I just manually converted my apt.conf to mockup
XML and absolutely hated it from the fift line or so.

> 
> >  And I'm not alone with 
> > my opinion in that.
> And apt's configuration gives me creeps all over the place:
> * Where's the grammar?

Run 'apt-config dump' - there's your grammar. The foo {blah
"something";}; can be considered a shorthand for the dump syntax.

> * Which options do exist?
> * When are which options used/set/initialized?

There are a different issue really. Now, I'm not at all opposed to
beating more sense into apt configuration system eventually (like
forcing options to be registered before they can be used etc) but that's
not solved by just switching to XML.

> 
> > >>  From programming point of view
> > >> I fully agree XML would be much nicer configuration file format. It's
> > >> just that XML isn't "human editable" IMO (programmers don't count as
> > >> humans here ;)
> > >
> > > c.f. above.
> > >>> But given your attitude, I withdraw my comment above. All your proposal
> > >>> does is adding yet another source of errors and of incompatibilities.
> > >>
> > >> Dunno, apt has a parser which does the job adequately and users are
> > >> already familiar with the format.
> > > Pardon again, IMO, a very short-sighted POV.
> > >
> > > apt currently has a swamp of key-values pairs, written in a proprietary
> > > block oriented language, hardly with any grammar.
> > 
> > ...just like 99% of the existing open or closed source software out 
> > there :)
> Agreed, only very few applications have well designed configuration
> languages.
> 
> >  It's just yet another bad configuration "language" among other 
> > things, at least I'm not inventing a new one here.
> > 
> > That said, there *would* be significant benefits to using XML, I'm not 
> > claiming anything else. What it would take IMO to switch to XML in apt 
> > configuration is
> > 1) convert *all* of apt configuration to XML
> Agreed. If apt's configuration language grammar was well defined, this
> would be trivial. As there isn't any formal grammar and as there isn't a
> finite set of options, this probably isn't "that easy".

The grammar is quite clear IMO, it's just there are two ways to
accomplish the same thing which can be used interchangably and in any
arbitrary order. The internal representation of the configuration data
is a tree which should be quite well presentable with XML.

What's not so trivial is the directives in apt.conf - #include and
#clear. XML is fine for presenting the configuration state but
"commands" such as those dont really fit in.

> > 2) provide basic tools for manipulating that data without having to touch 
> > the xml manually
> IMO, this is not fair.
> 
> There isn't any tool to provide this feature for current apt's
> configuration. So, all you are trying here, is to fight xml by raising
> additional demands.

Erm, fair to whom? Others have expressed their concerns about XML as
configuration format as well, it's certainly not just my opinion. If
this was a democracy you would've lost already :) 

You want XML configuration? Here's my suggestion:
1) convert apt's configuration class to use XML doc representation
internally
2) add methods for reading xml configuration data in 
3) add 'dumpxml' command to apt-config to allow automatic conversion
from old format to xml presentation
4) add tools for programmatically manipulating the configuration
5) eventually deprecate and finally remove the old format completely

1-4 can be done without affecting users at all unless they wish to
switch to the new format.

Oh and btw, all this has little to do with the original proposal of
making repository configuration use apt configuration engine instead of
using another cumbersome and very limited file format (sources.list).
The configuration system can be used right now for storing the necessary
data, if the config system is some day switched to XML the repository
configuration will automatically follow as long as the configuration API
is kept compatible.

	- Panu -




More information about the Apt-Rpm mailing list