Syntax ( long )
gerard at linuxfromscratch.org
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
> 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
-*- If Linux doesn't have the solution, you have the wrong problem -*-
Unsubscribe: send email to alfs-discuss-request at linuxfromscratch.org
and put unsubscribe in the subject header of the message
More information about the alfs-discuss