Automatic download

Vassili Dzuba vassilidzuba at
Thu Sep 12 15:11:06 PDT 2002

On Thu, 12 Sep 2002 14:58:41 +0000 (UTC)
jamie_bennett at (Jamie Bennett) wrote:

> > -----Original Message-----
> > From: Vassili Dzuba [mailto:vassilidzuba at]
> > Sent: 11 September 2002 19:01
> > To: alfs-discuss at
> > Subject: Re: Automatic download
> >
> > Hi,
> > 
> > Thanks for your appreciation of my patches ;-)
> > 
> > In fact, i would like to be able to 
> > specify at run-time
> > a category of element handlers (the concept already exists 
> > but it is driven 
> > by the "version" attribute of the <afls> element. If we 
> > implement this, one could 
> > have a set of handlers to execute the profile (the actual 
> > new-* handlers),
> > and a new set to build the bash script, and maybe other sets 
> > for as yet undetermined
> > purposes.
> Should be an easy change but I cannot for the life of me think
> of any really useful applications for this apart from your
> bash script building.

For instance, we might use nALFS to interact with several back-ends

> > One thing I would like to happen in the ALFS realm is some 
> > convergence of the DTDs,
> > with the definition of an "official" DTD. I used nALFS (that 
> > seems to me a very fine tool)
> > to generate a LFS configuration and i'm currently working on 
> > a BLFS profile,
> > but i would prefer that the other tools (Mark Ellis's perl 
> > implementation and halfling)
> > be fully interoperable. So, if the people on the list are not 
> > too tired of these discussions,
> > i think it's maybe time to start them again ;-).
> This is most definitely needed. There is no point writing profiles
> for one alfs implementation and then having to change/tweak them
> to work with another. If there is enough interest we should 
> decide on the official syntax pretty soon as LFS and BLFS
> become more recognised. Maybe propose a draft syntax that we can
> all comment on? Neven? Vassilli? Mark?
> > Vassili Dzuba

Well, i have one to propose...

My DTD is based on reverse-engineering the "new" syntax of nALFS,
plus a few added elements corresponding to the patches.

AFAIK, Mark's one is a merge of the "old" (with elements like
<prebuild> and <postbuild>) and the "new" syntax, but is not
a superset of nALFS one.

nALFS is relatively "dtd-agnostic", as it is able to work with different DTDs,
according to the value of the "version" attribute of element alfs. Current nALFS
supports both the old and new syntax. 

As i wasn't part of the previous discussions on the syntax, i just assumed that the new one
was better and didn't bother with the old one. As the corpus of existing profiles
seems rather limited, i think it is a quite reasonable approach.

Let's note also that it is not enough to define the syntax, but we need also to 
define the semantics. For instance, I lost some time a fews days ago before noticing
that the <sear_replace> element in nALFS doesn't support wilcards.

So, for the time being, i can propose as a basis for the discussion :
- a DTD ( )
- a documentation of this DTD in docbook ( )
  or html ( ) format.

Any comment on these documents is welcome...

> -- --------------------------------------
> - Jamie Bennett     - 18 St Peters Terrace - jamie at -
> - Software Engineer - Lower Bristol Road   -                   -
> - PCP Microproducts - Bath, England        -                   -
> ----------------------------------------------------------------
> -- 
> Unsubscribe: send email to listar at
> and put 'unsubscribe alfs-discuss' in the subject header of the message

Of course, once the profile syntax and semantics are defined, we can work on more
useful things, i.e. the profiles themselves.

I've stated to work on a BLFS profile, and would like later on to work on a profile
to build a LFS boot disk.

Unsubscribe: send email to listar at
and put 'unsubscribe alfs-discuss' in the subject header of the message

More information about the alfs-discuss mailing list