ALFS Status: Past and future [was Re: new guy, newbie questions.]

Felipe Contreras al593181 at
Tue Jan 22 11:16:51 PST 2002

On Mon, Jan 21, 2002 at 09:26:01PM -0800, Jesse Tie-Ten-Quee wrote:
> Yo,
> On Sat, Jan 19, 2002 at 08:58:17PM -0600, Felipe Contreras wrote:
> > As I have worked very hard for my own project since some time I think my
> > opinion whould be good at least to hear it.
> Of course, that's the least i can do for you. (especially considering
> all the conversations we have had on IRC ;)

Thanks bud.

> > I don't want to be pessimist, but I want to express my feeling that the
> > current ideas is not the right way. I like the idea of xml profiles, but
> > I think there should be more processing, lot's of things can be guessed
> > by some code and generate the finall commands to run.
> > 
> > There should be less hardcoded information so for example just having
> > "mcrypt" might install mcrypt with the defaults for every package. If no
> > more information is provided why not to guess it? We are talking about
> > an "automated" system, why no to make it smart an think the most it can
> > in order to help us?
> > 
> > There can even be different levels of processing an the corresponding
> > information can be stored somewhere. This requieres a little bit more
> > explanation but the point is that it's different to add a patch than
> > update the version.
> Actually this was first suggested by Gerard as a "smart profile" back
> when this project was first formed.  It most likelly will be
> implemented, allthough i'm not quite sure that's such a good idea for an
> initial release.
> [At least not yet, please prove me wrong if you can]

That depends, a "smart profile" has some commands in xml format tha
specify how to deal with it, like finding the version or something.

Or the "smart profile" is like I said, a simple xml profile that was
autogenerated smartly.

> > Also I don't like C for bash stuff, I even tryied Python but I had no
> > luck. It seems bash was not done to interact with it, but that doesn't
> > mean it can't be done.
> Nothing is impossible...

That's true, some while ago I decided that there is no other way, it is
bash, or it is a coshell.

A coshell is a shell process that receive commands trought a pipe and
report. In order to report the status of each command something like
"echo $? > /dev/fd/3" should be used after each command. That IMHO is
the best option for us.

> > Most of the work I've done has been to make a good and smart design so I
> > don't have to type everything. That's why I don't like the current
> > xml format, you have to specify almost everything! It seems much more a
> > script with vars like BASH-VERSION=2.05.
> Yes, i do have to agree with you there, it does seem like it's a script,
> allthough in reality it's just meta data.  Structured and stored
> information on packages.  Really we should be considering how we can use
> XSLT more.  Consider the implications of that.
> You could take a profile, write an XSLT style and convert it to any
> number of different formats, shell scripts, you name it.  Really i think
> that's where the power of ALFS will come into play.  We could problably
> even do the reverse also, that's a though, Eh? :)
> As for making it less "script-like" as you mentioned, even if we smart
> profiles, it will still look like a script (even though it isn't), so i
> don't really see any way around this.  Suggestions are more then welcome
> thou!

It's ok for the build steps, but I don't like to type all the cleaning
commands, install-log gereation, unpacking, patching, and suck things
that are can be handled by the code. Think about different source
directories, remote locations, .bz2 or .gz, let the user choose if to
generate an install-log or removing the build dirs (rm -r glibc-*), and
stuff like that. I really don't feel that should be included in the
alfs format.

> > I'll really like to work on ALFS, I even did a parser following an
> > approach that has alredy worked to me since a while, but no one except
> > Neven Has seems to care about my ideas. I'm sad you said "let's start
> > coding" since I don't like how stuff is going to be done, but anyway I
> > hope you have an open mind in order to accept new ideas, if not now,
> > later.
> Well, you can't please everyone.. however you can try, but i wouldn't
> recommend it, the outcome is usually less then what it would have been
> otherwise.
> Trying to make something "perfect" is a huge goal.  And can never be
> realized first time around, that's what revisions are for, take the
> LFS-book for example.

Sure, and it's a goal you'll never achieve, we're humans.

Felipe Contreras
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