Want to contribute

Tim Sarbin tim.sarbin at gmail.com
Thu Mar 11 13:46:29 PST 2010


On Thursday 11 March 2010 11:34:56 am James Robertson wrote:
> 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
> 
> 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 -
> http://www.linuxfromscratch.org/alfs/view/alfs-srs/alfs-srs.html.
> 
> 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 -
> http://www.linuxfromscratch.org/alfs/view/dtd/
> 
> 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
> decipher.
> 
> 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!
> 
> James
I have uploaded a screenshot of how I'm doing the calfs (console automated 
linux from scratch) application. I am doing a more wizardy style way of doing 
things instead of the old menuconfig:

http://img52.imageshack.us/img52/1283/menucq.png

I'll post a batch of screens up as I progress so I can get comments from you 
guys on it.



More information about the alfs-discuss mailing list