mark.uzumati at virgin.net
Tue Mar 19 06:21:35 PST 2002
On 2002.03.10 11:01 Neven Has wrote:
> I'm working on (finally) creating a profile for MSB's keep5-6 hint
> (that would be the best abbreviation I could think of ;).
> The main problem is setting the environment (PATH) after chroot.
> With <setenv> as it is now, this is possible, but only if none of
> elements fail after it. It they do, <setenv> won't be run on the next
> retry (independent of the parser used, it just doesn't have the reason
> so the environment won't be reset.
> I was thinking that we could change the way <setenv> works into
> something like:
> <setenv variable1="value1" variable2="value2">
> <!-- Whatever needs variables set. -->
> This way, <setenv> will have to be run every time some element inside
> This seems like a much better implementation to me, not only for
> the above problem, but in general. It somehow looks more closer to
> "setting the environment" really means (elements inside it being the
> elements inside that environment).
> Or not?
I kinda like the idea, but foresee a few problems. Firstly, you could
never validate this through a DTD, ever, unless you had a DTD with all
the variables you could ever want as attributes. On an aesthetic note,
do we want more "nesting" elements than we already have ? Dunno why i'm
mentioning this really, i'm undecided myself, just thought i'd throw it
As an alternative to another nesting element, we could put env settings
on the current nesting elements, maybe, probably makes little
difference. As to the validation problem, the only thing that springs
to mind is to have one "env" attribute that contained a string of
'variable=value' s, separated by something you are certain will not
appear in the strings themselves.
Would this then clear the environment space and put only these in, or
them to the current space ?
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