Profile splitting time!

Mark Ellis mark.uzumati at
Wed Nov 21 10:36:55 PST 2001

On 2001.11.20 12:38 Neven Has wrote:
> Two ways for splitting your profiles:
> o   External entity support is added. That means you can create your
>     profiles the same way LFS book is organized. Check out:
> http://www.beotel.yu/~has/projects/alfs/profiles/LFS-3.0-split.tar.bz2
>     for the example of this.
>     You can also have separate files for entities now. Read - support for
>     parameter entities is added (actually just enabled) as well.
> o   The advantage of <include> element (maybe not so obvious) is that you
>     can include _self_contained_ profiles. For example, using external
>     entities, you couldn't have entity declarations in the files
> included,
>     since they would appear somewhere in the file, which is not allowed
> in
>     XML of course.
>     But with <include>, you can have tons of profiles for various
> programs
>     which you can use separately, but which you can also "connect" in
> some
>     order, using a "master" profile.
>     Get 
> http://www.beotel.yu/~has/projects/alfs/profiles/after-LFS.tar.bz2
>     to see how it can be done.
>     This element is going to be improved a lot in the future. URLs for
>     fetching profiles from the Net will be allowed for example, multiple
>     locations if the first is not available etc. etc.
>     Right now however, you can safely use only:
>     <include>
>         <location>/some/location.xml</location>
>     </include>
>     Unless somebody gives us a reason for renaming these two elements,
>     future additions won't affect your profiles with the above.
> Neven

Good stuff Neven, looks like perl is playing catchup again :) I like the 
syntax, I was thinking more of <include> having the location directly, but 
this gives room for expansion. One thing I'm curious about, do you know if 
it's possible to use entities from the master profile in an included one ? 
I know it won't as you've written it, or at least i dont thnk it will, i'm 
just wondering if we can do it ? This would then allow you to change 
globals in the master, such as "LFS", without worrying about the 
sub-profiles. My thinking is if you could create a parser for the sub 
profile, copy the entity list into it from the master, then parse the sub. 
I have no idea if this is possible, any idea ?

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