New member with (possibly OT) suggestion

Jesse Tie-Ten-Quee highos at
Wed Sep 18 15:06:11 PDT 2002


On Wed, Sep 18, 2002 at 10:46:02PM +0100, Eddie Olsson wrote:
> My name is Eddie Olsson, I live in the UK (London) and work as a Programmer for CNET (ZDNet UK). I'm just about to start on my fourth major installation of lfs and I'm considering using ALFS, not so much for the convenience as for the repeatability of a scripted install.

Nice to meet ya :)

> One of the problem, as I can see it, with ALFS is that it's probably a lot of work keeping the profiles in sync with the development of the book. Wouldn't there be a lot to gain by merging the two processes? That way, you would always get an ALFS profile as part of the process of creating the book. 

Actually, believe it or not.. it's really not that much work.  Upgrading
profiles from one version to the next, is not really that hard.  It's
just a matter of changing a few entities when upgrading packages and
updating the syntax, whenever the installation instructions change (which
is very well documented in the lfs-book ChangeLog)

It only really becomes a PITA, when you start to move away from using a
BTB (By The Book) method, or more recently the new keep-ch5/6-sep as it
requires quite a bit changed to ALFS, not just the profiles.

> The core format for the book is, docbook sgml. A natural choice, but a choice that limits the book to human readable formats only (or almost).

Actually the lfs-book is in docbook XML, to be specific.

> ALFS, on the other hand, uses xml which is, again, a good choice, but the current DTD is entirely targetted at creating executable build scripts.

Hey, suggestions are always welcome on making it less like build
scripts.  Sadly i've been ignoring my ALFS work recently, other things
in life have been taking a higher priority...which always seems to
happen, right after getting back into working on it daily :P :)

> What if the book used a version of the ALFS xml format that had been extended to encompass all the elements needed for the book. We could then use that xml to generate ALFS profiles directly from the book, or build ALFS clients that would ignore, or make use of, the written instructions and explanations. To generate the currently used formats of the book, one would just transform it into html, pdf/ps latex, whatever, using XSLT or a parser. We could even generate docbook SGML from it.

This has been suggested, many, many times.  And eventually it will take
place.. when, I don't know :)  There are many different ways todo it,
and I wouldn't want to start such a project untill we can all go over
them with Gerard and the rest of the editors.

There was once talk about such a project however, named the LFS InfoSys.

> I'm sorry if this is OT as it borders between ALFS and lfs-dev, but I'd really like to see what you think of the idea and what can be done of it.

Id suggest moving this to alfs-discuss, where it belongs.  There has
been *alot* of OT things being discussed on lfs-dev recently, and sadly
this topic also falls under the OT'ishness =)

(yes, it does concern the book;  But I can garuantee ya, it wont happen
considering nearly all the editors and developers are re-adjusting there
lives, atm;  Gerard is moving, Ian just got married, Timothy/Myself/Mark
are all back in school, I have no idea where Marc is, etcetc.. :)

Anyways, if you want to discuss this further on alfs-discuss, feel free.
I've been meaning to get back on track with ALFS, perhaps this bit will
point me in the right direction, yet again.

Jesse Tie-Ten-Quee  ( highos at linuxfromscratch dot org )
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