Another try ( was Re: the forest through the trees )
corey at axcelerant.com
corey at axcelerant.com
Wed Jun 27 22:27:42 PDT 2001
Just before sending this I had a little light-bulb go off in my
head concerning the confusion and concerns we all seem to be having
over the portability issue.
I had in my mind only two forms of portability with ALFS:
1: *backend* portabality between programming languages.
( I hope we can all agree that this certainly is not our aim )
2: *platform* portability between the backend and the xml spec
( which can be remedied with a flexible command element )
BUT, there's a third that I simply wasn't getting through my head,
that I think others have been talking about but not clearly stating:
3: *profile* portability between systems!
I certainly apologize for not catching this earlier, it could have
solved some confusion. I simply was not thinking in terms of a
person/company/whatever hoping to define a profile that anybody
*else* could use. This is deservant of it's own thread.
Later this evening I'll post another long-winded, rambling, opinionated
email to start discussion on that topic... (c8=
So does everyone agree that there are three types of portability
which ALFS can focus toward: backend, platform and profile? Is
there any others?
So read the following with a mind that I was not taking into account
#3, if anyone at all gets through the whole thing without their
eyes glazing over, I'll feel like it wasn't a wast of time. (c8=
I hope I didn't get too overboard on this post - it's long, but I
really try stressing some points I've been trying to make that have
either been disagreed with, or that I perhaps merely have not
clarified plainly enough. I'm thinking I just might have to provide
some code and xml examples this weekend, so that I can visually explain
where I'm coming from.
And upon Thursday of June 28, the illustrious Gerard Beekmans spake thusly...
> > 4) unless Linux-From-Scratch is intended to be built from VMS or some other
> would be nice
Exactly - which is yet another reason for an extremely flexible method
for specifying commands and their parameters. Which I'm getting the
impression Gerard - finally someone! - is agreeing with.
> > 5) 99% of the build and installation process occurs from within a makefile
> > which uses basic unix commands and the bourne shell. (refer to point 3)
> Ok, but who are we to decide that the basic unix utils are good enough
> for certain situations.
> > In liew of the things, i think that the syntax for the pre & post install
> > commands should be something simple like:
> > <command>cp -R dir dest</command>
> > or if you want to go down the route of customization:
> > <!-- this user data entity could be in another doc -->
> > <user_data key="cp_options" val="-p"/>
> > <command>cp -R <user_data key="cp_options"> dir dest</command>
> Coming back to the statement made above and in my other email: you don't
> know for a fact that -R is available on the 'cp' you are assuming that
> somebody has. Parameters to cp and other basic utils may not change much
> or are the same on every system, but when it comes to other programs you
> don't want to rely on that. Perhaps you really need to use a non-gcc
> compiler that works pretty much the same but has a less parameters (say
> -malign_double doesn't exist, you could get an error when passing that,
> unless you describe it as something. Then you can decide whether you use
> it (by assigning a value to the description) or leave it blank if it's
> not supported on your choice of cc).
Exactly why I've been lobying for my 'command' tag markup idea:
<command name='mv' src='/bin'>
<opt name='-f' value=''>
<opt name='' value='/foo'>
<opt name='' value='/bar'>
( minus the 'id' attrs again )
The *same* routine or method in the backend will now *always*
be able to run the *exact* commands as specified by the *user*
in *his* profile. When the guy wants to use 'secure-mv' or
what-not, then he merely changes his profile -- or yeah, he
defines entities, so that he only needs to s/mv/secure-mv/
in one place rather than many.
His profile, his choice, *his* work should he decide to change.
Now we have this example that's been suggested:
<move src='/foo' dest='/bar'>
So the parser returns 'move' to the backend. So now you need to
make an associative array that points "move" to 'mv' ( along with
'link' to 'ln', etc ). And of course now 'mv' has a different
command syntax than 'ln'... so *now* you *also* have to write
friggin' if-else or whatever statements everywhere -- for every
command! That's insane. Not to mention you lose flexibility
in the spec for the users - what if, as part of their '<postbuild>'
profile for a certain package, we'll use the WindowMaker window
manager, the user wants to run the 'wmaker.inst' script? Sorry
chump, can't do it - nope, the ALFS does not allow that. So
the poor dude has to do *two* things to facilitate for his
requirement - first he'll need to define a 'wmakerinst' element,
and then he'll have to edit the backend source code so that
it knows what to do with a 'wmakerinst' tag... sheesh, who the
heck would want to work with a system like that?
You cannot, 1 - have the XML heavily abstract your data and,
2 - write the code to make guesses, assumptions and an indefinite
amount of workarounds - *either one* of those items are poor practice,
and I'm seeing people want to utilize *both*? You'll end up
developing/designing your way right into a dead end, with nothing
but an ugly mess to show for it.
LFS is our guidebook on what constitutes a base, bare bones linux
system, and what rudimentary packages and scripts, etc are required
to build that base. That's a HUGE groundwork which will be a major
piece of the automated process in ALFS - but it should *not* be the
basis by which we design the XML spec. Further, once we have designed
the formal xml spec - the backend should *rarely ever have to change*,
and should be fairly simple - the complexity goes into the XML
profile, the backend merely does what the profile says to do.
Basically: The 'alfs-sprofile' is an interface to modify the behavior
the backend, which does all the labor of the automated installation
and configuration of a customized linux environment.
> Perhaps I'm really overkilling this issue by wanting to be too versatile
> and modular and try to accomodate too much.
I, for one, don't think so - I think this is precisely how we
should design ALFS from the start. If we want this thing to
be highly usefull for a huge variety of people, then we need
to make sure that these people have the power and flexibility
to do exactly what they want. Basically, I'm talking about
designing a kind of "Meta-Linux" concept - can you imagine all
the universities, companies, research programs, so on and so
forth that would just *love* to be able to define and create
their very own, niche specific linux environment? With nothing
more than an xml document or three? If it requires that the
XML spec be complex in places - so be it. If it requires a few
days to a weeks initial effort - hell that's nothing. We design
the spec to be able to basically do *anything* ( within reason ),
and provide shortcuts via the use of defaults, entities, examples,
and so on and so forth. Allowing the novice to get something
defined real quick and easy, but allowing that university or
that bioinformatics research group to really whip out something
super custom, precise and extremely niche -- conforming to the
XML spec that the ALFS contributors have designed and running
that off the backend application layer that we contributors have
( I *really* don't think we should focus on portability at the
*backend* -- we should decide what language we want to write it
in, and that's that. If somebody decides for some freaky reason
to rewrite the backend in some other language - that's *their*
effort, not ours. I think perl or python fit perfectly with our
requirements. As far as portability on the *platform* end - that's
instantly and elegantly acheivable through allowing the *users*
to specify the platform dependant tools and commands used in the
xml profile, as I've displayed with the 'command' element. )
And so yeah - versatile and modular is killer; and it's going
to require some serious flexibility and design -- ultimately
that means we're going to need to be prepared for some complexity
> But if this is at all
> possible and easily done, why not. The less we force upon people, the
> better ALFS will be accepted and used I think.
I totally agree.
I stumbled on LFS by accident - I thought it was a super cool
resource and was really impressed. Shortly thereafter I started
thinking about how nice it would be for myself to automate my
own custom linux - once I started thinking about that, I began
thinking how cool it would be for *anyone* to automate there
own custom linux. Then came xml of course, then came the backend
planning, as well as some bootstrapping ideas - then I finally hit
on ALFS just recently and I thought - cool! this thing is already
being worked on! LFS set the precedent and has paved the way for
the next logical step, ALFS can prove to be a highly regarded and
well known/utilized project - so long as it is useful to a wide
audience. Why only go half way?
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