Lots of ideas

Felipe Contreras al593181 at mail.mty.itesm.mx
Sun Dec 16 20:09:23 PST 2001


I have been working for a year or might be more in my own packages
installer special for LFSers, somewhat like alfs, but since I've
received few (alomost nothing) feedback I've decided do close it,
althought I'll still work on it but just for me.

Before closing I want to make a final movement and I want to add alfs
support. I've been working on an alfs parser that might work for my
project, and I think it's almost done.

During this proccess I've found several details that might be of your

1. There should not be commands alone.

IMHO each command should have an identification, be inside a package
like vim, or inside something like "creatingdirs", that way, no commands
are floating scatered. The advantage come when you want to resume the
installation, or select special steps on it, it's much easier this way
to indentify those commands that are not under any container. Something

<package>			<commands>
	<name>...			<name>...
	<prebuild>...			Like *build
	<build>...		</commands>

2. The steps might be not static

Instead of defining just 3 steps, it will help to have any number of
steps of any kind of name. That will only help if in the future the ALFS
format want's to be more simple, and have defaults for some kind of
steps, like <step name="make"></step> might be easier and the default is
obvios. It will also help if the installation is not that simple, like
the zlib installation, that you have to clean out everything and specify
some other options, it will be good if there could be more that only 3

Another issue what I called the "init" step, that is executed always
before the rest of the commands, for example if you were resuming the
build, the "cd ?/glibc-2.2.4" will be executed properly. Currently the
ALFS specification specify a "base" for all the commands, and I think
that's not the proper way to do it, it might help in some cases, and it
should be left as an option, but the "init" should be too.

3. The information should be divided

I think eack package have a lot of information that will be better
handled if it were divided. For example, I think that the "setup
information" have nothing to do with the current tarballs and patches,
tarballs change, but the "setup information" might not. The tools that
read this information can easily generate instructions to unpack the
tarballs and patches. Also there is the "misc information" like the
licence, author, download location, etc.  and it will not fit in the
current alfs format. Finally there is the "build information" that says
what package to setup one by one, when to chrooted, etc.

I know this is a great change and I think it will not be well accepted,
but anyway that's what I think that should be done.

4. C Front end-Back end no no

As I stated in a mail ago, "a bad thing about alfs in c", there might be
problems with the "execute" tags. There might a lot of discussion but
the point is simple, there is no natural way to interact with bash in c.
Believe me, I tryied to move my project from bash to c, and I never
figured out a nice way to check what bash was doing. I tryed pipes,
checked out sockets, and a lot of things, and at last I know that it can
be done, but really I didn't want that level of complexity for something
so simple. So if you ask me, c should be banned for executing shell

5. The solution

The solution from my point of view, is to write an alfsparser as I'm
doing right now. This parser should receive as input what package, step,
and number of command to parse and it will return the parsed sh
command ready to be executed.

	command: ./alfsparse LFS-3.0-new_syntax.xml
	output: creatingdirs ... gcc gcc.static ... fstab

	command: ./alfsparse LFS-3.0-new_syntax.xml gcc
	output: prebuild init build postbuild

	command: ./alfsparse LFS-3.0-new_syntax.xml gcc prebuild
	output: 5

	command: ./alfsparse LFS-3.0-new_syntax.xml gcc prebuild 1
	mkdir $build_dir/gcc-build

I hope the point is clear, and altought I'm not so sure how the perl
FE/BE works, I'm pretty sure that an alfsparser like this will help a

Well, these are the my ideas, and I have worked with a program that
works with this design and a lot more and I didn't have any problem
developing it, so I think these ideas can't be so bad. I hope you have
an open mind and hear them.

PS. Anyone interested in the current code of the parser please let me

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