What next? [Was: Re: LiveCD or No LiveCD?]
Alexander E. Patrakov
patrakov at gmail.com
Tue Feb 26 22:44:15 PST 2008
2008/2/27, Gerard Beekmans <gerard at linuxfromscratch.org>:
> Without a better ALFS integration, people are going to find themselves
> unable to use LFS in production on more than one computer. I could not
> see myself running vanilla LFS on the servers I maintain at work. One is
> doable but not even full time when you have other duties. When you end
> up with a dozen or more systems, you either get ALFS working, or you
> give up and go back to a distribution.
> Package management has been brought up by various people. It's a simple
> requirement if you plan to use the system for a while, besides just
> learning. ALFS would be able to tackle that problem as well.
Thanks for bringing these two points close to each other. Indeed,
automating the build and setting up the infrastructure for seamless
upgrades & tryouts is important even on one machine. It is even more
important if the actual distribution of packages to the other machine
is going to take place.
However, there is one more thing I would like to see: something that
avoids newbies' attempts to build LFS directly on their i486-class
laptops (when they also have fast Athlons) and thus only waste time.
Something is needed that shows how to use a faster computer as a build
factory for i486, so that one only has to transfer the result to a
slower machine in a binary form. Or how to make a binary backup for
the case when something is screwed up.
BTW, a solution that shows how to build for i486 without the kernel
uname hack is already in the LiveCD repository (but it can and should
be transformed into the toolchain and perl ./configure arguments and
thus separated from the other config.site hacks).
> What if ALFS became the main way to do an LFS system? You might argue
> the fact that it takes away from the LFS methodologies. There is great
> benefit to be had from doing it all manually. But let's be honest - the
> majority of the book is running configure, make, make install. Does that
> really provide much educational value? It's not like you can actually
> read the output fly by on modern machines. In years past you could
> sometimes read along and get an idea of what it was doing. Not so much
> anymore. And not really important unless you're a programmer too and
> have an interest in knowing those details.
No objections. Using some form of ALFS would certainly eliminate
errors due to stupid typos, and won't remove the educational value at
all, because the process of creating or adjusting the configuration
files is the real learning experience.
However, there is one requirement on the ALFS implementation: it
should be easy to deviate from the book intentionally and experiment.
Jhalfs may or may not be the best solution.
Of course, the rationale notices for the existing ./configure
arguments and patches should stay in the book, and rationale notices
for not using certain "broken" arguments or not upgrading to a
"broken" package version should, IMHO, be added.
> LFS started out as more of an LFS+BLFS combined (read the 1.x series).
> Then it was decided to split the core of LFS from the optional parts as
> the optional parts are too user specific. Not everybody likes a chosen
> email program, web browser, etc.
Here is a little problem, because the split point before which there
are no optional packages is not well-defined. E.g., one may want to
compile gpm before ncurses in order to be able to click through the
dialogs in pure ncurses-based applications (that know nothing about
gpm) on Linux text console. On the other hand, for a server without
mouse, or for a person who spends all the time in X window system, gpm
is just a useless package.
Also there was a discussion (without conclusion) whether to treat
autofoo as optional packages.
> I don't know that we want to merge LFS and BLFS in its entirety but
> maybe ALFS can become the "official" glue between the two. If nothing
> else, to take away the manual burden of trying to install all the needed
This would require some work on the BLFS side. Namely, making sure
that the default ./configure arguments don't result in a package with
a severely cut-down functionality just because adding the rest of the
arguments pulls down the dependencies marked as "optional" (i.e., a
more clear distinction between "optional" and "recommended"
dependencies). Then, making a statement about which sets of optional
dependencies and ./configure flags were actually tested.
Alexander E. Patrakov
More information about the lfs-dev