Alternative format for the configuration file

[Free Ekanayaka]

|--==> "OS" == Otavio Salvador <otavio@debian.org> writes:

  OS> [1  <multipart/mixed (7bit)>]
  OS> [1.1  <text/plain (7bit)>]
  OS> || On Tue, 27 Jul 2004 16:27:15 +0200
  OS> || Free Ekanayaka <free@agnula.org> wrote: 

  fe> Are variable configuration keywords  really necessary? Actually  I did
  fe> not  realised that the  "_sarge"  suffix was  refering to  the [sarge]
  fe> section until I read the above lines (well I guess  it in some part of
  fe> my brain, but it's a  little bit unusual  for configuration files so I
  fe> dropped that thought).

  OS> This is to provide a filter for a specific backend while merging it.

IMHO this  further filtering  is a  confusing.  I would  move  all the
filtering statements in the merge section,  and use the remote backend
as unfiltered  APT sources, that define  the set of  all the available
packages.

E.g.:

[sarge]

server = http://ftp.debian.org/debian
sections = main
distributions = sarge

[my_cdd]

backends = sarge
filter = sarge:section:base sarge:priority:important
get_sources = true

  fe> I don't know what the filter_sarge keyword  is supposed to do exactly,
  fe> but I   think it can be   replaced by static   keyword,  like filter =
  fe> sarge:section:base or something similar.

  fe> Whatever   config format we  choose,   IMHO we  should avoid  variable
  fe> keywords.

  OS> I don't see a good scheme to do it.

  fe> Yes, I didn't  claim compatibility with other  APT tools. It's just to
  fe> have a consistent format between them.

  fe> Regarding simplicity, I  think there  is  room for  improvement in the
  fe> schema I proposed,  however   I  think  that good  documentation   and
  fe> meaningful comments can make everybody happy.

  OS> hehe

Let me add that  in this case the  configuration file is not a  simple
flat list of variables, that defines paths, options, switches etc, but
it's rather similar  to a tiny programming language,  used to build up
your CDD using wide APT pools as raw bricks. 

This  is   why  I  think  that   the   configuration file  should   be
hierarchically structured.

Note also  that formatting of  the style that I  proposed is  free and
that instead of:

FooList
{
        Item1;
        Item2;
        Item3:
}

you can write:

FooList { Item1; Item2; Item3 }

that results in a shorter file.

After all  I  don't really  find  this format more difficult  than the
current one, as it has a simpler syntax:

<SECTION> ::= <KEYWORD> "<STRING>"; | <KEYWORD> { <SECTION> };

instead of

<VARIABLES> :: <KEYWORD> = "<STRING>" | <KEYWORD> = "<STRING>" <VARIABLES>
<SECTION> ::= [<KEYWORD>] <VARIABLES>

Cheers,

Free Ekanayaka

[0] http://lists.alioth.debian.org/pipermail/partial-mirror-devel/2004-July/000009.html