Profile generation (XML DocBook => ???)

Tapio Kelloniemi persistent.spam at
Tue Mar 7 12:52:00 PST 2006

Hi list

I've been thinking about this "parsing commands from the books" problem for 
awhile and read some discussions here. I haven't reviewed Makefiles generated 
by jhalfs, but I feel that the currently used parsing method has a problem:
We need to decide what commands to accept from the books for execution. In LFS
book we don't have many commands that should not be executed (except for those
in Making the LFS system bootable -section). In BLFS, however, we have many
such commands, for example commands in sections "Additional X Window System
Configuration" and "X Window System Components" should never be executed
automatically. But as far as I understand, these commands are also enclosed in 
<userinput>...</userinput> tags in the book sources. I don't like the idea 
that all of these exceptions (which are very numerous in BLFS) should get 
special handling in the parser. Not even talking about conditional execution, 
like: "If you have [A] or [B] installed, execute {AA}, otherwise execute 

I feel that some metainformation should be added to the book sources
themselves, for example in the form of specially formatted comments, if XML
DocBook is not flexible enough. These comments would not be a big maintainance
problem for the book editors, but would be a great help for alfs developers. 
It may be argued that there are many LFS editors who will most like dislike my 
idea and that alfsers are minority in LFS builders, but I ask how big the 
minority will become when we have a full-fledged build tool ready made.
But back the the idea of metainformation:
In addition of telling the the alfs parser that the following commands from
the book should be executed, these metainformation comments (or whatever)
could give some more details to the parser, for example the conditions
under which it should be executed. Also information such as the following 
commands apply patches could be provided. This information could then be 
displayed to the user who is building a system (or editing generated 

Another issue that has been in my mind and which has not yet been resolved is 
the output format that will be generated by the command parser. For jhalfs 
this is makefile-format, but obviously this is not sufficient for a full 
building environment. nALFS uses XML profiles, but these are not 
easy to edit. To me this seems as a very important concept, since:
1. LFS is not a ready-made distribution and almost every LFS user makes many 
   adjustments to the way their systems are being built.
2. It should be quite easy for the alfs tool to read generated profiles and 
   execute commands based on that. alfs should not have intimate knowledge of 
   features and command-line options of various Unix utilities (has nALFS
   has to), but rather should just pass the commands to an 
   interpreter which can tell if they completed sucessfully. In the most 
   extreme cases, the builder should be able to replace bash with tcsh and 
   with proper editing of profiles should be able to build a system with
   his/her preferred shell.

Again I feel that a new format should be introduced, which would be easy to 
parse by alfs and especially easy to read, write and edit by humans. simple 
Shell scripts are not enough since then the alfs daemon cannot tell which of
the commands in the script failed, if shell just exits with error code 1.
I also think that some variable references must be present in the 
generated profiles to make it more easy to build different versions of
packages than those that the books use. For example in BLFS many packages'
documentation is installed to package and version specific directories under
/usr/share/doc. If the package version is changed by the builder, only one
command should need modification (eg. VERSION=...) instead of modifying all
those mkdir and install commands.

I would like to here some comments regarding my views of the future of alfs 
and the books. I believe that it would greatly help alfs development, if the 
book itself would blend towards alfs, without abandoning its important goals. 
The most of LFSers would probably be interested in automated building 
of their systems and therefore ^.*LFS.*$ should co-operate.


More information about the alfs-discuss mailing list