Want to contribute
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
> 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!
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:
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