An alternate automation approach?
csheets61 at sbcglobal.net
Mon Aug 8 22:32:33 PDT 2005
I have debated broaching this subject for several weeks. Dont crucify me
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
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
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