Planning an overall direction for LFS

Bryan Kadzban bryan at
Thu Feb 28 19:09:12 PST 2008

Hash: RIPEMD160

Jeremy Huntwork wrote:
> The reason for this, I think, is because the discussion is taking
> place among LFSers. :) We're all a bunch of control-freaks who like
> to do things our own way.

That's a really good point...  ;-)

> but I think, for the sake of customization and flexibility, it will
> still be good to break down LFS into 'modules' as Alan Lord
> suggested.

That sounded good to me as well (assuming it's actually possible, but I
think it is).

> Generally, I like the idea. A PHP generated book that allows for 
> customization and automation in a manner suited to the end user.

I'd shy away from PHP, but that's just because I'm a die-hard Python
user.  :-P

Depending on the language (and libraries available), it may even be
possible to generate the web stuff automatically from the XML sources.
It would depend in part on what tagging we can do (although I bet that
an XML-Schema or Relax-NG schema for DocBook would be better suited for
it, as we can then group pieces based on our own namespace and schema).
If we can figure out a way to add our own tags to each current page,
saying what module it belongs to (or however it would work), that'd make
it fairly easy.

Actually, at that point, it may even be possible to generate the HTML
directly from the DocBook using some kind of XSLT.  I'd be more
comfortable if it was done in a traditional language, but that's just
because I don't grok XSLT much at all.  ;-)

(And if that kind of thing is workable, the "barrier to entry" wouldn't
have to be a whole lot higher than it is now.  Writing the server side
code could be done once; the XML would still drive everything.  There
may be a few occasional maintenance issues with the scripts, but the
main book development could probably still happen in XML.)
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla -


More information about the lfs-dev mailing list