My conclusions

reb0rn jyork at
Fri Jan 25 22:38:42 PST 2002

On Sat, 26 Jan 2002 01:00:21 -0500, Felipe Contreras wrote:

> Hi all,
> Well after all the discussions I've been I've came up with some toughts,
> might be you'll like to hear them.
> In summary these are my ideas:
> * Grouping
> 	I think grouping is essential in order to control exactly where we are,
> 	which commands are going to be executed, save the current state,
> 	restore from where we left, etc. I think no scatered commands should
> 	lay around, it's like seeing just a bunch of commands in the lfs book
> 	witouth information belonging to which chapter it is and which part of
> 	the chapter you'll not know if to type those commands or not.
> * Profile's Limit
> 	In my opinion the xml profile should not be a bible of what to do with
> 	a package, there should be some limits and distribute tasks along the
> 	profile and the implementation. If we add tagas for each and every
> 	feature that we want to implement, like <if> or <remote> or stuff like
> 	that the usefullness of xml is going to be missunderstanded and we'll
> 	end up with another project like a bash script that assemble .asm
> 	files.
> 	If we can agree here, then lot's of stuff can move from profile space
> 	to code space, it will all depend on the kind of functionalitly, if
> 	it's data or code. Something very important that I think the current
> 	profiles-implementations are lacking is the relationship data-code,
> 	like for example a global <base> tag for the whole profile so you don't
> 	have to type it everywere, just where the <base> is not the one of the
> 	profile. The code will take this information and act on a specified
> 	way.
> * Modularity
> 	I think a single xml profile for everything is not good. Now it seems
> 	to be the best solution, and most stuff can do it fine with just that
> 	information. But if we envison the future we'll probably see that a
> 	single place to have everything is not good, it's hard to maintain,
> 	extend, design and even read. Spliting the information of the packages
> 	seems natural to me, I mean, you have your sources, the setup
> 	instructions, some miscleanious information like author, homepage,
> 	licence, etc. Oviously The code to handle this information is
> 	different.
> 	Think about the preparation part, where all the sources are extracted,
> 	and patched, etc. What if I alredy have the sources, and just want to
> 	run the setup instructions, like for example I downloaded the code from
> 	cvs. We are thinking that we should always <unpack> something, if not,
> 	then we should change the profile, just because I want an alternative
> 	mode of operation.
> 	So, I think the preparation part (source tree) should have a different
> 	handling than the setup instructions, I consider them different things.
> * Posible Implementations
> 	From my point of view there are 4 kinds of posible implementations:
> 	1. The xml profile is translated to bash, then executed.
> 	2. The profile is translated to shell commands and each one of them is
> 	piped to a coshell that executes them and return the status.
> 	3. Each command is translated to shell command and simply executed with
> 	system() or something.
> 	4. Each command is handled directly by a system call or function.
> 	Each one of them has it's pros and cons, and it all depend on the
> 	language of the implementation. Probably the implementations will have
> 	to use some sort of convination, since for example an implementation of
> 	the 4th alone will not handle "./configure", ther is no way to do that
> 	without system().
> 	So, if we want to make a good profile we should think about this 4
> 	approaches of executing commands.
> There is more stuff, but I agree with Jesse, we should start with
> something now. If these ideas are at least considered I'll be happy with
> the path alfs will take.

I would agree to all of this accept for limiting the profile for reasons
i wont punish the group by stating again :)

Unsubscribe: send email to listar at
and put 'unsubscribe alfs-discuss' in the subject header of the message

More information about the alfs-discuss mailing list