Book XML design specs, extending LFS

Gordon Schumacher gordon at rebit.com
Sat Nov 22 10:08:28 PST 2008


So I've been looking at the book XML in more depth, since I'm definitely
interested in getting involved in the LFS projects.  I've been looking
mostly at the CLFS book, since much of my hardware is x64-based.  In
looking at it, I've found myself wondering if there's an "overall
design" sort of document somewhere that talks about best practices, and
why things are put together the way they are.

Particularly, as I mentioned, I'm interested in what would be considered
to be the best way to "extend" an existing book, in a way that's most
compatible with the existing books.  For the case I'm after at the
moment (the bootable ISO), the vast majority of the steps would be
identical; the only differences would be some extra steps in the kernel
build, the boot scripts, and an extra step after installing packages.  I
can think of three ways to do this:

1. Add a new attribute (perhaps "profile.condition=iso"?) to the
Makefile, and add the extra steps to the existing XML.  This has the
greatest impact on the existing book, but also is the easiest to keep
the new steps in sync.  This might not be easily maintained as a patch.
2. Add a new directory within the book for the new build type, mirror
the directory and file structure, and use XInclude/XPointer to include
all the identical pieces.  This is zero impact to the existing book, but
is much harder to keep synchronized.  This could probably be maintained
as "unpack this tarball into the BOOK directory".
3. Make it a whole new book, starting its life as a copy of an existing one.

As the person who's looking to do this, of course, I'd personally prefer
#1 - but I also recognize that means that I'm playing in somebody else's
sandbox.  The advantage here is that I'm more than happy to help with
the mainline development, since it would all fully apply to my build as
well.  For instance, I have succeeded in building CLFS with newer
versions of several of the packages - is there somewhere I should
forward those changes to?

My eventual goal (via jhalfs) is to be able to get pushbutton creation
of "appliance" CDs.  I've been using a heavily-modified Slax image, but
ultimately I need more control over the final product than I can easily
get with Slax.  So I'd be interested in helping with jhalfs development
as well - for instance, distcc support in jhalfs would be a wonderful
thing (I've been using it with good success in CLFS builds, albeit with
a lot of manual help).

So - what are your thoughts on the best way for me to proceed with this?



More information about the lfs-dev mailing list