Profile splitting time!
mark.uzumati at virgin.net
Thu Nov 22 11:05:41 PST 2001
On 2001.11.22 16:34 Neven Has wrote:
> On Wed, Nov 21, 2001 at 06:36:55PM +0000, Mark Ellis wrote:
> > I was thinking more of <include> having the location directly, but
> > this gives room for expansion.
> One thing that I had in mind is:
> <include type="package"> <!-- "profile" for the way it works now -->
> which would include a single <package> from the profile stated in
> That would be useful for those wanting to keep instructions for multiple
> packages in a single profile. For example, I remember Paul Campbell had
> a profile called mother.xml with tons of <packages>s in it. So with the
> above, one could just select and include only some of them.
I like it lots, it's giving me a headache figuring out how to do it, but
hey :) I suppose we'd parse in the mother.xml, move through it looking for
<package> with the name and version we wan't, and copy that branch into
the controlling profile, not too bad actually.
> > 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,
> > 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
> > I have no idea if this is possible, any idea ?
> It's possible, but not in some clean way (at least I don't see it yet).
> I don't think that there is a way to copy the entity list from parser to
> parser (since resolving entities is probably the first thing parser
> but we could trick him. :) We could feed the sub-parser with our own
> entity declarations, using the entities from the main parser. Right after
> the sub-parser's start handler for Doctype is called is a good time to do
> that. All this belongs to "I think" category. :)
> Anyway, if we try something like that, should we do it by default, or
> when requested?
> I don't think it should be default, since the profiles included would be
> again dependent of their master profile, which is not always suitable.
> And it wouldn't be "pure XML" any more.
I was thinking of allowing entities specified in the child profile to
"overwrite" any matching ones from the master, that way you can get system
stuff available and if the child profile wants to override or simply not
use them it can, so a default isn't necessary. This just makes the "i
think" category even more hypothetical of course :)
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