Want to contribute

James Robertson jwrober at gmail.com
Thu Mar 11 08:34:56 PST 2010

Tim Sarbin wrote:
> James,
> I have been looking around at the ALFS source and it seems to pretty much be a 
> fancy shell script, please correct me if I'm wrong. I'm not really following 
> the client/server model that I was reading about. Also, what do you mean by 
> "ALFS project SDMS"?
> The proto I'm working on would have to deal with both LFS as well as BLFS in 
> one way or another via the xml source. The goal of what I'm working on is 
> something that can either create a fully bootable system on the host (via the 
> live CD possibly), a bootable ISO, or a base system in a specified folder. I 
> would have a separate back-end and front-end, that way the LFS could be built 
> via console or a GUI yet retain the same business logic (really that's how I 
> code everything anyway). My logic is already pulling the xml of the LFS book 
> and determining the set of binaries required to build from the host system 
> (pre-build check), and hopefully tonight I can get the first part of the build 
> process done. After that I will link to what I have and see what the ALFS team 
> has to say about it.
> Thanks,
> Tim

Current ALFS source was the precursor to jhALFS that most folks use.  As 
you are now aware, jhALFS is a master shell script that builds out make 
files and such.  It is very good at building LFS and marginal at BLFS 
(unless you handle the deps yourself).

As for SDMS - I used the wrong acronym.  I meant SRS - Software 
Requirements Specification.  It is here - 

I have read the other posts and I think you are on the right path.  The 
main goals of the project was to provide a small component that runs as 
a daemon on the new host.  This would generally be provided by a boot cd 
or something.  The daemon could listen on a simple unix socket and also 
on other protocols like TCP/IP assuming you have a stack to work with.  
The daemon is responsible for issuing the commands on the host that 
compiles the package and installs it.  A full featured gui client 
(whether that is an ncruses one on a screen or a full window manager 
supported one written in QT/GTK is an open discussion) would then 
communicate with the daemon to issue commands on the new host.  It would 
be responsible for all the logic, package management, downloading of 
files, logging etc.  So in essence the client is "smart" and the daemon 
is "dumb".  You are going to want to become familiar with the ALFS DTD 
as the SRS asks for the commands from the book to be parsed as profiles 
in the ALFS XML Schema (which is used by nALFS today).  It is here - 

I also see that you are on the right path with extracting the commands 
from the book.  LFS is pretty easy, BLFS is another animal as the 
pre-requisites (both optional and required) are going to be hard to 

I'd be happy to test.  I use jhALFS today and it works, but would really 
like to see a full ALFS happen.  Thanks so much for picking up the torch!


More information about the alfs-discuss mailing list