Use of Xinclude with nALFS

Vassili Dzuba vassilidzuba at nerim.net
Wed Oct 16 13:06:48 PDT 2002


Hi,

Maybe the following will interest somebody...

The profiles LFS-4.0 and BLFS on my site are in some way
"monolithic" profiles because they consist of a single XML
document, with all the entity declarations stored in a single place.
As LFS and BLFS are integrated projects, this is probably
the way to go, as it allows to manage the entity declarations
(and in particular the package version) in a single file.

Now, let's think about a "postblfs" that would include all the 
packages in the universe, known and unknown ;-)

It would be unreasonable to put the declarations for all these
packages in a single place, as the profile for each package will 
probably be written by manu different persons, and each user will
select the packages he/she want to install on his computer.
We can however think about of database of profiles.

Let assume, for instance, that Mr X developped a profile tardy.xml, and
Ms Y a package io.xml (these are two packages taken almost randomly
on today's freshmeat delivery).

These packages will be complete XML documents, and we will be able 
to run nALFS on them idependently:
 
     nALFS tardy.xml

Now let assume that Mr Z, for some reason, want to make a profile
that includes tardy and io. It cannot use entity references because
these files contain full XML document, not XML fragments.

Here comes XInclude.

To build a profile with both tardy and io,
it is enough to write something like  :


<!DOCTYPE alfs SYSTEM "nalfs.dtd" []>
<alfs version="3.0"  
      xmlns:xi="http://www.w3.org/2001/XInclude">

  <xi:include href="tardy.xml"/>
  <xi:include href="io.xml"/>

</alfs>


If this file is called MyBundle.xml, one can call nALFS on it :

     nALFS MyBundle.xml


As XInclude is supported by libxml2, this functionality is available
with nALFS out of the box (after compilation, of course ;-).

Of course, it would be better is the two profiles
are coherent in some way (e.g. the package directory and the build
directory are the same).

If we assume that the profiles have been developped independently
but with the idea to be stored in some future CAN (Comprehensive ALFS Archive),
CAN could require that they both include a predefined external entity
that contains a few entity references used by all the profiles, e.g.

	<!ENTITY packages_dir   "/var/packages/packages-POSTBLFS">
	<!ENTITY build_dir      "/usr/src">

and that could be modified locally, in a single file.


Vassili Dzuba



-- 
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe alfs-discuss' in the subject header of the message



More information about the alfs-discuss mailing list