Conrad's ALFS comments

Conrad Newton conrad.newton at
Tue Aug 27 02:54:47 PDT 2002

On Mon, Aug 26, 2002 at 10:15:35AM +0000, Rui Ferreira wrote:
> Hi all,
> Hi Conrad.
> You posted your script as an answer to my call of making an unified bash 
> script for building an lfs system.
> Well, yours is pretty close, if not exactly.
> So, I'm going to tell you what I would change:
> . Put the functions on another file to help readability;

I have been relooking at the script recently, thinking that
I might make a new version called install-lfs-cvs, and I agree
with you that one could improve readability by breaking 
the script into pieces.

If you take a close look at the script you will see that it
divides into the following parts:

 7%	lines 1-59	variable definition
38%	lines 60-378	functions
26%	lines 379-593	error checking
10%	lines 594-676	preparation of $LFS directories
17%	lines 677-819	compilation

If I were to divide the script into two parts, however,
it is not the functions that I would remove first,
since they are  logically connected to variable
definition and especially to compilation.

The part that stands out as logically disconnected is 
the error checking.  While it may be useful, error
checking is not central to the script's purpose.
If you have a set of lfs-commands that you know to be 
correct, you may even regard the error checking as a 
pointless nuisance.  So that is the first part that
I would separate out.

If you want to make more than two parts, then you could
of course remove the functions.  I suppose this is a matter
of taste.  As Bill Maltby said, some people prefer to have
everything in one file so they can do quick searches and
jump from one point to the next.  It should not really be
a problem in any case, since most good editors allow you
to divide your screen in two and view separate parts of the 
same file simultaneously.

> . The function names are very easy to read but too long. Instead of 
> make_lfs_command_chroot, why not just mkcommchr;

Bill Maltby has already done an excellent job of addressing this question.
I would only add the following point.  If I had written a library of
functions that were to be used by other programmers every day (e.g. ncurses),
then perhaps it would make sense to have command names like mvwaddch.
These commands are not self-explanatory, but if you do a lot of curses
programming you get used to them, and the short function names make
them easier to type.  My install script is unlikely to be used every day 
by anyone!  Thus transparency and long file names make good sense.
Once every three months you will look at this script, and then with
luck you can quickly remember how it worked.

> . Using lfs-commands from the site might not be an good idea because future 
> versions might reveal incompabilitys and you'll have to deal with them by 
> changing the functions;

Now we are getting to the really interesting part:  maintainability.
Before I say any more, I should emphasize that the two main points
to this script are transparency and maintainability.  The script 
should be understandable by a newbie, and it should still be useable 
a year from now, when all the package versions have changed, with
(ideally) only a minor rewrite.

Chris Lingard has answered this question in superb fashion.
I will only add a few more words.  

When I first wrote this script, I attached all the version numbers 
to the package names, but it quickly became clear that this was
a nightmare.  I cannot keep pace with software development elsewhere, 
and I cannot keep pace with the LFS/BLFS developers.  I chose to use
the lfs-commands for the same reason that mutt does not have its own
editor, because it is better to do one thing well than to do two
things poorly.  Put slightly differently, if a highly competent person
is willing to do the work for you, why make extra work for yourself?

>From the point of view of the script, very little has changed since
LFS 3.1 (see
There are some new packages (just change the variables static_packages
and dynamic_packages), the command names are now capitalized (to avoid 
confusion with the package names, I suppose) and the CVS version builds 
chapter 5 in $LFS/static.  It cost me very little to make these changes.
The details of package building are completely uninteresting to the script,
precisely because it uses the lfs-commands as external functions.

> . Entering chroot to execute each package build saves you from having more 
> than one script, but it isn't elegant(?!?). 

:-(  no?  and I was so pleased with this solution!

> I came up with something else. 
> The script could call himself with an argument like stage2 for example;
> . If using functions in other files, the main script could (elegantly) look 
> like (just some examples):
>      Create directories # Being 'Create' a function and 'directories' the 
> argument;
>      Install bash-2.05a static # 'Install'=function, 'bash...' and 'static' 
> the args;
>      Install linux-2.4.18 headers
>      Configure vim # 'Configure' function just copies the file that should 
> be edited by the user;
>      Install glibc-2.2.5 dynamic addon glibc-linuxthreads-2.2.5
> (Usage: Install package static|dynamic|headers [addon|patch 
> addon/patch-file])
> Here, if we are allready making an exception to the kernel headers, we 
> could as well open another for config|menuconfig|oldconfig|xconfig;
> . Rob Landley as a good way of creating root's password, check this:
> # Default root password is "password" -- change this!
> rm -f /etc/shadow &&
> cat > /etc/shadow << EOF &&
> root:IO3r0vZygY5qI:11875:0:99999:7:::
> chmod 400 /etc/shadow
> Well, these are just some.

Leaving aside all these details, I agree that the script could probably
be made even friendlier and nicer-looking.  I took it for granted that
at some point my script would be superseded by a better program supporting
menus and profiles, a la nALFS.  Perhaps it already has been superseded.
But for most people, bash is still more accessible than curses and XML.


> And your script isn't stupid. It does far more checkings!
> Care to comment?
> Greetings
> Rui Ferreira
Unsubscribe: send email to listar at
and put 'unsubscribe alfs-discuss' in the subject header of the message

More information about the alfs-discuss mailing list