My conclusions

Felipe Contreras al593181 at mail.mty.itesm.mx
Mon Jan 28 11:30:02 PST 2002


On Mon, Jan 28, 2002 at 09:49:29AM -0800, Jesse Tie-Ten-Quee wrote:
> Yo,
> 
> On Sat, Jan 26, 2002 at 12:00:53AM -0600, Felipe Contreras wrote:
> > * 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.
> 
> Yes, i've never liked having some of the commands outside of a package,
> but there isn't really all that much we can do, unless we make a dummy
> package and put them inside it or move more of the config file generate
> into there correct affiliated packages.

You decide, we think about a way or we just leave it until it comes
itself. IMHO a <commands> or <setup> should do it, might be the name
should be changed.

> > 	1. The xml profile is translated to bash, then executed.
> 	
> This i believe you are doing.

True.

> > 	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.
> 
> This is how nALFS does it, i believe.

What about the third?

> > 	4. Each command is handled directly by a system call or function.
> 
> This is how id like to see things done.
> 
> > 	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().
> 
> Correct.  Well system() is an evil system call and it's much nicer to
> use a PIPE imo.

True, pipes are much better.

> > 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.
> 
> *blinks* He agrees him me!?! *blinks again* How long have i waited for
> this day.... :)

LOL, those long discussions need to lead to this, doesn't?

Anyway I'm sad this is not design/implementation but simple project
management :/

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



More information about the alfs-discuss mailing list