mark.uzumati at virgin.net
Fri Mar 22 04:18:08 PST 2002
On 2002.03.21 21:26 Lee Saferite wrote:
> On Thu, 21 Mar 2002 13:26:16 -0500
> "Seth W. Klein" <sk at sethwklein.net> wrote:
> > Mark Ellis <mark.uzumati at virgin.net> wrote:
> > Stages would have to nest and attribute values would have to be
> > inherited.
> That is what I had in mind and seems to make the most sense.
> > Can this replace package then? I think it can. It would add a
> > element for packages, too. (I forget what that was called last time
> > someone suggested it.)
> I would think keeping <package> would be a good thing. It is a
> logical element for grouping. Then you could use <stage> inside it to
> subdivide it any way you wanted. That way, you could have an <info>
> entity with some required info on the package ie. <name>, <version>,
> <defaultbase>, possibly some sort of depenancy info. Then the rest
> would be all stages or just naked elements (correct term?)
I'm definitely for keeping package as a distinct element, there will
always be a use for specific functionality at the package level,
particularly dependency info. When i eventually get around to finishing
it :) my installation tracking will capture anything done within a
particular <package>, and i would imagine Neven has worked on similar
> As for the env seperator problem, I have very limited xml
> savoir-faire, but I would ask, can you have nested quotes in an
Yep, thats not a problem at all, and one solution would be to put each
assignment in quotes. Only drawback is that the assignment could
contain quotes too, which isn't a show stopper but would require a
lovely bit of logical gymnastics to match up the encapsulating quotes.
> An uglier option could be to have some sort of <info> element (maybe a
> differnet name) inside the stage element. You could then have a
> series of elements that set all the needed options. Actually, I think
> that sounds bad, and ugly...
> <env mode="append">"you=me" "he=she"</env>
> Actually, having written the above, I think that looks nicer that my
> first suggestion. You could make the stageinfo element a sigle
> instance only and required. inside the stageinfo element you would
> have a required <name> element but the rest could be optional but
> unique (only one instance).
This could work, and you could have repeating <setenv>s in the
<stageinfo>, formatted like they are now but tied to that particular
stage. If you then need to rerun something in that stage, the stage
setup is performed again, including any <setenv>s that are tied to it.
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