ALFS-API 0.1

Bryan/Jesse/Gerard alfs-discuss at linuxfromscratch.org
Thu Jun 29 07:58:18 PDT 2000


Hi all,

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

Definitions:
------------

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....

<alfs>

<package>
	<name>
		Ed
	</name>

	<pre_install>

		<depends>
			static build
		</depends>

		<depends>
			some package
		</depends>

		<get_method>
			http://somearchive.net/latest-ed.tar.gz
		</get_method>

		<patch>
		</patch>

		</pre_install>

		<gcc>
		</gcc>

		<configure>
			configure --prefix=/usr
		</configure>

		<make>
			make -e
		</make>

		<make_install>
			make install
		</make_install>

		<extras>
			cd /usr/bin
			mv ed red /bin
		</extras>
		
</package>

<package>
	<name>
		Patch
	</name>

	<pre_install>

		<depends>
			static build
		</depends>

		<depends>
			Ed
		</depends>
			
		<get_method>
		/usr/src/packages/latest-patch.tar.bz2
		</get_method>
				

		<patch>
		</patch>
	
	</pre_install>

	<gcc>
	</gcc>
	
	<configure>
		configure --prefix=/usr
	</configure>

	<make>
		make -e
	</make>

	<make_install>
		make install
	</make_install>

	<extras>
	</extras>

</package>

<env>
	some env variables here
</env>

<logs>
	/var/some/log
</logs>

<configfiles>
	/etc/passwd=/premade/passwd
	/etc/group=/premade/group
</configfiles>

<special_commands>
	mount drives, create filesystems etc. like chap 4 from lfs-book
</special_commands>

</alfs>

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 
understandable.

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 
upon.

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 mailing list