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 Wed, 28 Jul 2004 17:00:10 +0200
  OS> || Free Ekanayaka <free@agnula.org> wrote: 

  fe> Practically speaking what I'd do would simple be:

  fe> 1) download the Packages.gz and Sources.gz file from whatever APT
  fe> repository I want to use

  OS> After it, the mirror of the backend with the needed packages is doen
  OS> and a pool for it is populated.

  fe> 2) generate my custom Packages.gz and Source.gz according to the
  fe> rules (filters/include/exclude/resolv_dep_using) defined in 
  fe> the config file

  fe> 3) populate the pool/ fetching the relevant packages, and possibly
  fe> deleting the old ones

  OS> No. This uses the previous packages of merged backends and populate
  OS> with hard-links it.

  fe> I think  such  approach grants   you a  great degree   of freedom when
  fe> filtering/merging repositories together.

  OS> No.

  OS> We provide, currently:

  OS> You got all packges from sid and then, on merge, you use only
  OS> base-packages.

But this way  I have to  download (and  possibly  update) a  number of
packages I'm not interested on.

For example let's say that you'd like to have all the base system from
sarge, except for  some  special packages for  which  I want  to  have
bleeding-edge versions from sid (this is a typical scenario for me).

What I want  to be able to do  is to have  those packages  and resolve
their dependences using sarge packages wherever possible, and grabbing
additional packages from sid only if necessary.

Is this  possible with the current  schema? And, if yes,  do I have to
download the  whole sid  base-system  even if  I'm interested  only on
getting a few packages?

  >>>>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. 
  >>>>
  >>>>[rest of explanation snipped]

  NLB> OK, Free, let me square with you.  If you want me to sit down and throw 
  NLB> away the last 3 weeks or so of work on the new configuration format, 
  NLB> you're going to have to give me a better reason than "this other format is 
  NLB> prettier".  The current (newly rewritten) config format isn't the best 
  NLB> possible one, I agree, but it's very flexible, very easy to read, and does 
  NLB> everything we need out of it.

  NLB> If you were to show me a grave problem with the current format, then I'd 
  NLB> consider throwing it away and doing something different.  As it is, I 
  NLB> don't see a good reason to rewrite this code.  If YOU want to sit down and 
  NLB> rewrite it, rather than just telling me to do it, that's great, and that's 
  NLB> what Free Software is all about, and we'll talk about it when you've got 
  NLB> patches ready that pass the test suite. :-D

  NLB> As it is, I'd rather get to work on the actual functionality of this 
  NLB> program, instead of quibbling about details of the (IMO, rather 
  NLB> superficial) config format it uses.

  fe> I perfectly understand your point, and I do agree with it. However if like
  fe> the alternate format too, I can find some time to write the changes to the
  fe> Config.py module myself.

  OS> I currently, doesn't found a good reason to do it now. I think we have
  OS> other more important things to do and this, if needed, can be done later.

Yes, that's true. Let's concentrate on other implementation issues.

Cheers,

Free