alfs-discuss at linuxfromscratch.org
Thu Jun 29 07:58:18 PDT 2000
We would like to say the ride on ALFS has been alot of fun. We
think we have seen alot of good discussion on the mailing-list(s). We hope
to see more....
We made this document to help provide a static reference point for our
continual discussions and a hopefully a place for the new ALFS API.
Ok, we have this problem of trying to define how LFS is installed, or
works after a base install. Everyone has an opinion which is a *good*
thing. What we need to define, though, is a framework in which everyone's
choice can be fullfilled. And once someone gets to a certain point like
say, optimized everything, then they could map out those details for
others to follow.
ALFS will define how that framework works and what a map looks like.
Not the details per se, but more along the lines of defining what is
a map, how do you use it, get something meaningful out of it, show how
others can make maps, etc.
Let's begin to define our map/framework...
Here is the basic structure we have thought of so far:
front-end <---> profiler <---> profile <---> compiler
front-end: could literally be anything, command prompt, boot prompt,
gui, ncurses, web, whatever. It's job is to collect and present
information to the user, you know a front-end :)
profiler: tool that talks to the lfs compiler through making a profile
and feeding that to the lfs compiler. The lfs compiler sends back it's
messages to the profiler. The profiler feeds the front-end with these
and possible other messages. It also takes from the front-end the user
input to make the profile.
profile: defined parameters that program the lfs compiler to do something.
Current idea is for an xml design. See examples below... (aka
configuration file, play is to make this modular to easily add packages)
lfs compiler: dumb tool, it's only job is to take the defined
parameters, perform the job and report back it's results. Simple
example it './configure; make; make install's a package.
So the real problem comes in the profiler and profile steps, as it is easy
to create front-end and lfs-compilers.
How does the profiler be the middle man and what does the profile look
like? That still is open for discussion, but here are some examples, ideas...
Start small, say we are automating just the part of lfs where you enter
the chroot after the static install and you are automating the
installation of ed and patch.
This is what a sample profile for that might look like....
mv ed red /bin
some env variables here
mount drives, create filesystems etc. like chap 4 from lfs-book
I (Jesse) threw in some extra ideas at the end there. I got the ideas from
looking at all of lfs's commands, and from Richard's alfs scripts.
I am sure the profile will be expanded in many ways as we add
features, but this is just to give you an impression and I hope it is
This profile is what is fed to the compiler. As you might have
noticed the compiler does more than just './configure; make; make
install'. The compiler itself knows how to handle an <extras></extras>
tag and the data contained within.
Otherwise the compiler sends back messages to the profiler. The
profiler keeps track of what is going on, errors, i guess later
stored profiles, etc....Whatever it is that we define the profiler's
abilities to be.
For now we think we should define a LFS 2.3.5b "profile" and get a
compiler working to compile that profile from scratch. On the
other end we need to work on a front-end that interacts with a
profiler and how it creates a profile. Then we can test it out
with a LFS profile that is created through the whole process of
front-end <--> profiler <--> profile <--> compiler
without any errors. Once we get there we can begin to define all
the choice that we can think up...
This is only a basic system that ALFS can be based on, no details have
been addressed... We would like to see a system that we all agree on,
like an API or a blueprint that we can use for development and fall back
To recap, instead of concentrating on the actually profile like everyone
is right now, we should start with at least a system where everything else
can be build on. (the profile is just a part of that system, lets make it
as versatile as possible)
If we give an API for each tool and set a standard for the profile, we can
hack on each part and be sure it's all well integrated together ;)
Bryan Dumm <bdumm at bobby.bcpub.com>
Jesse Tie Ten Quee <highos at cadvision.com>
Gerard Beekmans <gerard at linuxfromscratch.org>
-*- If Linux doesn't have the solution, you have the wrong problem -*-
Mail archive: http://www.pcrdallas.com/mail-archives/alfs-discuss
IRC access: server: irc.linuxfromscratch.org port: 6667 channel: #LFS
Unsubscribe: email alfs-discuss-request at linuxfromscratch.org and put
"unsubscribe" (without the quotation marks) in the body of the message
(no subject is required)
More information about the alfs-discuss