Syntax ( long )

Gerard Beekmans gerard at
Thu Jun 28 04:54:53 PDT 2001

>   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 

Yes, the former.

And yes, our first profile will probabl be a standard lfs system, just
because it's already available and a good test bed.

>   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.

I agree. In a system profile you could define once something like
<!ENTITY makeprog "/usr/bin/make">

or whatever way it'll be done. Then just reference &makeprog; every time
you want to run make on a Makefile. Then you only need to change it once
and the entire ALFS system will be using a different program.

I don't believe in hard-coding anything, not even a simple thing as
/bin/cp. Just define it as a variable somewhere in a system-wide profile
and if you have a better cp program you can just change that one line
into <!entity cpprog "/usr/bin/secure-cp"> and you don't have to go
through every profile or backend or whatever to see if they are still
using /bin/cp somewhere to do copy work. Hard-coding these things is
just bad and I think we can all agree on it. You want to be 200% sure
that if you change something in a profile there's no sneaky backend
ignoring 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.

Right. You want to tell what is being done, not how it is going to be
done. So a -f parameter to a copy tag would be bad. Who's to say that
our secure-cp program uses the -f parameter? Instead you'd want to
describe it as "force" and "recursive" to replace -f and -R
> 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.

"Automated installation of any custom Linux, as specified by any number
of profiles" would be the answer. A standard lfs system will just be one
of hundreds of available profiles.
>   Apparently we're still in the early desing stages - so let's
>   keep up the excellent feed back.

We are and yes let's do that

Gerard Beekmans

-*- If Linux doesn't have the solution, you have the wrong problem -*-
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