An alternate automation approach?

Chuck Sheets csheets61 at
Mon Aug 8 22:32:33 PDT 2005


I have debated broaching this subject for several weeks. Dont crucify me 
too bad.

Although I have only been working with LFS for about a year, I have over 
20 years in IT, 15 years as a unix System Admin, and 10 years dedicated 
to automated system builds.

I know how difficult it is to do what you do and I understand that
choices have to be made. There is a lot of very hard work here
and I dont mean to belittle that by any means. I wouldnt be anywhere 
where I am in my efforts today without the LFS approach and community.
I want to give back somehow.

Consider this as feedback and feel free to file it as you see fit.
Please forgive me if anything here is incorrect. I have never actually 
executed nalfs
I do understand that many of these points I make are arguably just an 

The first thing I looked at in LFS was the automation (current tool and 
proposed reqs). I found a few conceptual "concerns" that turned me away.
1. There is no end-to-end bootstrapping capabilities
2. It doesnt appear to allow for a well organized and self contained 
working environment to create a pristine build
3. The tool cannot be used with a base LFS system.
4. XML may be a wave of the future, but it has nothing to do with basic 
Linux and the
goals of LFS. Why should I have to learn and use it if wont help me 
after the system is created? (I dont like Java or the "M" word either)
5. Any secondary "engine" required to parse commands denotes a 
What if it doesnt handle something exactly the way I want it to?
6. I dont see anything dealing with packaging, versioning, and layering 
of the resulting builds.
7. (I personally dont like the licensing - but thats not a technical 

Although in many applications I am sure this is nothing short of a 
miraculous tool,
I cant use the current or proposed ALFS project approaches.

I am not suggesting that the current direction should not be continued.
Only wondering if I am the only one who would like to see an 

So I wrote my own. end-to-end, bootstrap to installable cd creation, 
fully automated and menu driven, Nothing but Bash. (Just because its 
bash doesnt mean its a novice approach, it can be maintained and tweaked 
by a lot more people that way -
more available developers)

Im far past base LFS and currently working on various and asundry tools,
NON-LFS additions (web100/speech/etc), and BLFS application installs.
I have been through all this once under the 5.1 LFS release, Im 
upgrading to 6.1 (base LFS is done), making it a bit less tailored to my 
specific needs, and general cleanup in anticipation of going public with 
it sometime in the future.

Dont get me wrong - the stuff I have wont do cross compiles,
hasnt been tested with many architectures, doesnt yet easily provide for
tailored compiler options, and needs to be more generic in some of
its approaches. I am not a Linux internals expert, I am not an expert in 
compiling software, but I do have extensive experience in managing 
integration, releases, deployments,  and build automation. There is a 
lot of room for improvement in the code I have, but hey - Im just one 
guy with 5 machines and a full time job.

I dont yet have the resources to look into making this code available to 
general public (mostly those annoying licensing issues that I hate so 
much but some coding too).

Seriously, Im not trying to knock whats been done already - Im sure its 
a great tool
under the right circumstances, Im not trying to say what I have is 
but it is different.

Your software is out there for everyone to see and use - mines not 
You must be the pros. With all due respect - Im following in ground you 

Is there any interest in looking at an entirely different approach to 
Or is everyone pretty happy with the current direction?

Feel free to tell me to take my football and get out of your baseball 


More information about the alfs-discuss mailing list