Syntax ( long )

corey at corey at
Mon Jun 25 04:52:13 PDT 2001

And upon Monday of June 25, the illustrious Corey Cox spake thusly...
> corey at wrote:
> > > 
> > 
> > <command id='1' name='mv' src='/bin'>
> >   <opt id='1' name='-f' value=''>
> >   <opt id='2' name='' value='/foo'>
> >   <opt id='3' name='' value='/bar'>
> > </command
> > 
> Sorry, I have to strongly disagree here.  

  No apologies necessary!  (c8=

> As soon as we start to write in what
> command has to be used for a step we lose portability.  


  Last time I looked, cp, mv, rm, patch, ln, configure, and make
  were commands all found on every unix system I've ever sat in
  front of. Isn't a running *nix environment the main requirment 
  before installing an LFS system?

> The idea of the tags, IMO, is that they should say what is being 
> done and give the data to do it - not dictate how it has to be done.  
  Did you mean: "give the data to the _program logic_ to do it"?

[ NOTE: below this I'm going to get pretty wordy and verbose -
only so that I'm being as concise as possible about my ideas and 
questions, so that there's little confusion ]

> If we decide to use different tools later we will have to do a lot of 
> rewriting.  

  So - then, same difference: either you do a lot of rewriting in 
  the code ( the program logic ), or you do a lot of rewriting in 
  the XML... ( chicken and egg, anyone? ) 

  ( Though, to be fair, it can be said that it would be easier
  to simply change a couple lines of code in one or two source
  files, than to go and change every instance of 'make' to 'pmake'
  throughout multiple xml documents. )

  But I really don't agree that there would be much rewriting of 
  anything at all. You say above that, "we" will have to do a lot 
  of rewriting. It could be that I'm way off base here - so let me 
  know! - but I was under the impression that what we were designing 
  here, is a way for anyone, by following the specifications provided 
  by the ALFS, to build their own linux system.

  So, to summarize - are we building a *framework* and an *interface* 
  by which to create _one's own custom linux system_? Or are we actually
  defining a single, concrete automation process to create a "Standard 
  LFS System" and *only* a "Standard LFS System"?

  I thought it was the former, but that of course one of the first actual
  implementations would most likely be a "Standard LFS System", as per 
  the most current LFS-Book.  If, when you say "we", you are referring 
  to whoever becomes involved in _adhering to the ALFS specification as 
  defined by the DTD to create the Default LFS System_, then yeah - as 
  maintainers of the 'alfs-profile' for the default LFS system, you will 
  have modify *your* profile's xml if/when you decide to change tools.
  This doesn't mean me, as maintainer of "Corey's Bare Bones Linux", has 
  to also change *my* alfs-profile, just because the standard LFS system 
  suddenly decides to use 'pmake' instead of 'make'.

  So, as a designer of an xml document which will ultimately be used
  to automate generation of a customized linux environment - wouldn't
  you prefer to have a spec which allows *you* to decide what tools
  and programs will be utilized in order to build that environment?

  It seems more universally usefull to allow the *user* decide what
  tools to use - not us.

  As I see it, our goal is to create an XML spec that allows a person 
  to generate his own linux, and then we write various programs, 
  utilities and or scripts that will act on the xml provided by the 

> I don't think that is the way XML is supposed to be.  Our data should 
> stand alone no matter how we decide to use it.  

  I don't believe XML's primary purpose is to *abstract* your data,
  as you say -- but, rather, to *describe* your data.  Now, how one 
  *applies* that data is a matter of design and implementation, which
  occurs within the code logic of whatever is parsing the xml.

  So the point is raised - and you've raised a good one - perhaps we 
  need to clarify exactly what direction and aim we have in the ALFS. 
  It's actually a simple question that will easily resolve the design 
  philosophy behind the profile XML spec.

  Here's the question:

Are we designing and implementing a system to automate installation
of a "Standard Default LFS System", or are we designing something
more broad, which enables the automated installation of any custom
linux, as specified by any number of specific alfs-profile authors
and/or maintainers?

  The above would be what I'm not currently clear on.

  ( Personally, I like choice number two - the broader vision - but
  I'm new here and so may have already missed out on that stage of
  the decision/design process... )
  Of course ALFS will use much of the information and processes
  currently provided by the noble LFS project - I was thinking
  ALFS will use LFS as springboard of how to build a base, or 
  "template" linux system, but go a step beyond that by: 

A - providing a standardized specification/interface for the
    structure and design of one's own custom linux environment.


B - providing the program(s) used in actually applying that
    specification in order to automatically generate, build and
    install said custom linux environment.

  I don't believe the ALFS should dictate what tools/programs
  are used to build a system with - it should be what the *user*
  wants to build with - the ALFS should merely do what the user
  says; the user directs the ALFS via the alfs-profile xml doc.

  Is there agreement here, or am I on the wrong path?

> Also, I really don't think it looks cleaner - it is cleaner that that 
> particular example, but that was only a preliminary definition anyway.  

  Well, that is completely a matter of taste for the most part -
  definitely of no real consequence at this stage.

> We still need to do a lot of work on this.

  Definitely! That means the more everyone interacts and throws ideas 
  out now, the better and more successful of a project we'll all be 
  part of; this is cool.  (c8=

  Apparently we're still in the early desing stages - so let's
  keep up the excellent feed back.



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

More information about the alfs-discuss mailing list