Want to contribute

Tim Sarbin tim.sarbin at gmail.com
Thu Mar 11 12:12:04 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
Who do I need to contact to get write access to the ALFS wiki? I'd like to 
move these specs I've written up to the wiki for peer review instead of just 
keeping them locally. Also, I have created the base for the alfs shell client 
and the alfs daemon server (it's a real daemon). When you compile alfs (which 
compiles everything, including the daemon and frontends), it has ./configure 
options for things like filtering the communication types (tcp/pipe/file) among 
other things.

Anyway, someone give me (essial) write access pretty please :p



More information about the alfs-discuss mailing list