automated profile generation
bookreader at gmx.com
Thu Mar 18 22:25:02 PST 2004
Thank you for your attention!
On Thursday 18 March 2004 14:47, Hui Zhou wrote:
> On Thu, Mar 18, 2004 at 01:12:20PM +0100, Reinhard wrote:
> > Is there someone willing to have a look at those generated profiles?
> You are doing something I have planned before. I didn't really work on
> it because of shift of interest and scarce free time. (When I
> finished lfs and have a seemingly stable comfortable system to work
> with, and the time schedule is tight, it's very easy to abandon some
> some ideas although I felt very interested initially.)
:-) I know what you're talking about.
> In case you didn't receive much response, I would like to encourage
> you. Keep up the good work as long as you having the fun. When you
> have something and would like someone to lookat it, post it up.
Well I was blamed out of blfs-dev as they stated automated processing is an
item of dump users who like brainless installation.
My position is quite contrary, as I believe, that automated processing is the
base for certain quality.
I'm not that good in copy by keyboard and quite errorneous.
So with LFS I put the commands together in few Makefiles and startet the build
after chapter 5 (with a clean fs) until the build succeeded with 2 or 3
With BLFS I wanted to have the same security, but with that lot of packages I
negated big keyboard copy-sessions.
The tools I found worked with blfs 1.0 - and the book changed that lot, that
the tools I tested didn't work with the current release.
Additionally I wanted to learn perl, as I often need to do quick text
So I wrote a script to build a Makefile based on my package selection.
Then I builded a server upon LFS with the scripts. Naturally I had several
bugs in the script, but when I was done with the server, the script matured
that much, that I could also use it for quality-investigation of the book.
Well, as I'm quite a perl-newbee, the script is not at all "high
sofisticated", but it works. And is it is build with modules, it's easy to
As I found no interest in blfs-dev supporting (or even admitting) automatic
processing, I took a closer look at ALFS.
Well, my opinion is, having a book like LFS or BLFS as knowledgebase, it is
poor practice to need additional information sources.
I very like the way to teach linux, but I don't like to have to copy the
build-instructions by keyboard.
So what do you think about patches to the blfs-book to correct the
dependencies or other details needed for automatic processing?
Those patches could be saved in the ALFS-repository ...
> I don't really use nALFS now, but I can quickly pick it up and try some
> test if I got the time.)
Well, I did not either. But as I got so much out of LFS and BLFS, I wanted to
give a bit back to the teams and for so I spend time to edit the book and
expand my script.
As it already is able to handle dependency walking and generates
build-commands, it's only adding another module to add profile generation.
> The automated work may never rival a manual one. And when your
> automated profile have significant different structure than the manual
> one, the use of the automated profile is limited at least for those
> using manual profiles currently, who won't just throw away their
I really don't want anybody throw away anything! -
I downloaded the profiles from LFS 5xx and I worked with the dtd and
crosschecking the profiles.
Most differences are IMHO cosmetic i.e. some packages change the working
directory during the build commands, so it's not enuf having the base in
stageinfo - so I added the base to every command.
Hope the command is able to check, whether it needs the base information or
How is the handling of environment vars just for a single command?
I did not find a profile for alsa-driver yet, theres a CC=... just before
the ./configure and I remember other builds, where CFLAGS where set after ./
configure, but before executing make.
What is the right way to do this with ALFS?
More information about the alfs-discuss