enhance blfs-tool and make custom-tools on running system

linux fan linuxscratch at gmail.com
Wed Sep 10 09:09:52 PDT 2008

One can learn from the blfs book while creating custom-tools scripts to be
included in a jhalfs build. I wanted to get the blfs-tool to create scripts
in the same format for packages that require complex dependency
calculations. I also wanted to find some way to get jhalfs to build
custom-tools after the system is built and up and running.

What is evolving is a modified version of scripts.xsl which produces scripts
in custom-tools format, a customized Makefile.custom for jhalfs to make from
custom-tools after the system is up and running, and a few scripts to pull
it all together.

This is an example run:
cd ~/blfs_root
make (... I selected w3m ...)
cd /jhalfs
sh remake_custom.sh
sh make_custom.sh


The file scripts.xsl exists in /jhalfs/BLFS/libs and in ~/blfs_root/libs.
  ~/blfs_root/libs/scripts.xsl :

The script BLFS_TO_CUSTOM copies the modified format scripts generated by
blfs-tool to /jhalfs/custom/config assigning a number computed as highest
preexisting number + seqence number.
  ~/blfs_root/BLFS_TO_CUSTOM :

The script remake_custom.sh recomposes Makefile.custom based on all the
files in /jhalfs/custom/config and makes them scripts in
/jhalfs/lfs-commands/custom-tools. Additional, it downloads sources and
patches that do not preexist in /sources.
  /jhalfs/remake_custom.sh :

The script make_custom.sh just does this:
make -f Makefile.custom $*
  /jhalfs/make_custom.sh :

The Makefile.custom is a watered-down version of jhalfs (LFS build) Makefile
that doesn't really do chroot and it just does CUSTOM_TOOLS.
  /jhalfs/Makefile.custom :

Caveat 1:
Packages with oddball naming conventions like
gc6.8.tar.gz, links-2.1pre33.tar.bz2
may not perform expected dependency checking function due to the difficulty
of calculating a name for /var/lib/jhalfs/BLFS that coincides with
~/blfs_root/packages. Manual adjustments required.

Caveat 2:
Some patch names ending in other than .patch would get ignored.

Caveat 3:
The xorg7 workarounds were too extensive for me to convert to "custom-tools
Possibly, it might be desireable if there was a blfs book xml entry for each
and every one of xorg7's, in build order, tarball to download, and patches
and notes. I realize there are about 300 of them which is a big F.O. (future
Then one might construct scripts from the xml and during the build and have
restart capability in case of a mishap. Current blfs xorg7 primarily teaches
one method to run the special scripts to build it. Xorg site teaches
different methods to run scripts to build it. Someone may want to learn
building individual components to understand their place function in the
scheme of things. Or maybe somebody wants a personal preference such as
without XCB or without Mesa.
Notwithstanding, the current workarounds for xorg7 are ingenious and
excellently done.

Thus far, the resuts have been very positive. It is welcome to know there is
a script and a log record, in a centralized place, indicating how a package
was configured and what install commands were used. Sometimes there is a
posibility to "configure" and "make uninstall". Other times manual commands
to remove it might be calculable.

LFS can make the best systems.
This is my 2 cents.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfromscratch.org/pipermail/alfs-discuss/attachments/20080910/51e7c149/attachment.html>

More information about the alfs-discuss mailing list