Another try

Gerard Beekmans gerard at
Fri Jun 29 06:09:13 PDT 2001

>   OK - there's my own hang-up I've been having all along, and which
>   unfortunately seems to have caused so much chaos and confusionl
>   Sorry guys - I really don't mean to be stiring the shit here - so
>   just kick me out if I'm simply being unreasonable and counter
>   productive to your project.
>   But I personaly just think that we *should* be telling it ( the
>   backend ) *how* to get the job done. That's what a custom anything
>   is all about - *you* dictate what and how you want *your* item
>   to end up like.

Imagine you're a profile writer, not a backend coder. You're Joe Doe who
gets his hands on ALFS and wants to install openssh and openssl along
with a basic LFS system. He/she takes a sample profile from for example
bash to look at a working profile and accordingly constructs the openssl
and openssh profiles. Joe Doe really doesn't need to worry that he has
to actually tell the backend how to process this. He just writes a tag
that somehow should make the backend do a "./configure --prefix=/usr &&
make &&  make install".

Can we all agree on this Joe Doe case?

Back to you and I quote

But I personaly just think that we *should* be telling it ( the
backend ) *how* to get the job done. That's what a custom anything
is all about - *you* dictate what and how you want *your* item
to end up like.

In a way yes. You add a tag or two that cannot translate into anything
but "./configure --prefix=/usr". That will be _exactly_ what you want
the backend to do. But the backend writer should be free in choosing
his/her own implementation. Perhaps the backend writer thinks it's best
for his language to start a bash shell which runs "cd
packagedir&&./configure --prefix=/usr". In case of configure that's
probably what ends up happening no matter what. But when we come to
"make" and "make install" we don't have to run that in it's own shell
perse. The backend can call the make program directly like this:
	"make -C packagedir" but the user never said anything about the
-C parameter. It could be implemented to be added.

So, the profile does not tell the backend whether to start a bash
process which runs make, or whether to run make directly. All the
profile tells the backend, is something like "you need to run make, 
somehow and it's up to you how you do it, just get it done.


Can we all agree on this example too? I think Joe Doe and this last one
captures the confusion and disagreement we're having.

I just outlined how I personally envision things.

>   I'm comming from an angle where the xml profile is an open
>   specification for directing specific orders to an automated
>   process ( the "backend" ), so that it ( said backend ) will 
>   obey completely my every command as to produce a linux environment 
>   tailored *completely* and in *every way* to my exact specifications.
>   In my vission, the xml spec tells me how to talk to the back end 
>   and *give explicit directives* - verses, in the seeming direction
>   of ALFS, the xml telling me how to say *what I'd like to do*, so 
>   that the backend makes the decision on how to go about doing it.
>   Subtle and similar - but ultimately very different approaches.

True, but you probably don't have more than one backend or do you?
In a bash backend we don't have much choice but to run a bash shell that
runs make. But in a C or C++ backend we don't necesarrily have to run a
bash shell before we can run make. There's a big differnece there.
That's why the profile only specifies to run 'make' and the backend has
to decide how it's done best. Every language will have a different way.
Heck, perhaps there will be a korn shell for all we know, so we don't
want to dictate "start bash, run make in it" when we actually want a
"run korn, then make" situation.
> Ack!

Welcome to design ;) Everybody has his own ways, experience and visions.
I'm sure we'll be able to come to a middle ground. As long as we stay
civil and not bash eachother's heads in we'll be allright.

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