Syntax ( long )
corey at axcelerant.com
corey at axcelerant.com
Mon Jun 25 04:52:13 PDT 2001
And upon Monday of June 25, the illustrious Corey Cox spake thusly...
> corey at axcelerant.com 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
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
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 linuxfromscratch.org
and put unsubscribe in the subject header of the message
More information about the alfs-discuss