mark.uzumati at virgin.net
Fri Mar 22 04:18:03 PST 2002
On 2002.03.21 18:26 Seth W. Klein wrote:
> Mark Ellis <mark.uzumati at virgin.net> wrote:
> > On 2002.03.21 09:28 Lee Saferite wrote:
> > > I like the idea of <chroot>, <su>, and <setenv> but for
> > > (or mybe to make it more complicated) why couldn't we have a:
> > > <stage name="Ch.5 - Installing Bash" root="/some/dir"
> > > group="lfs" env="E=mc2">
> > > You could use the attibute addenv to append to the env. and you
> > > have all env changes be aplicable only to elements of the stage
> > > I mean, if you look at it, every time you do a setenv or su or
> > > you are entering a 'stage' of the building process, no?
> > > Comments/Flames welcome. =)
> > I think i like this, it might seem messy at first 'cos you'd have to
> > have most of those attributes as optional, but its versatile and
> > even replace *build :) <ducks/>
> <looksinnocent/> ;)
> But strangely enough, i think i like it too. Lets see...
> I didn't think i liked the name "stage", but on second thought, i
> i do like it.
Had the same reaction at first, but it sounds right now.
> Stages would have to nest and attribute values would have to be
> inherited. Example:
> <stage root="/some/dir" user="lfs">
> <stage user="root">
> <!-- stage.root is "/some/dir" -->
Yep, sounds good.
> Can this replace package then? I think it can. It would add a grouping
> element for packages, too. (I forget what that was called last time
> someone suggested it.)
No, see my other reply.
> So i have
> wd="/" <!-- working directory, hoping that someone would think
> of a good name 'cause i haven't -->
Do you intend this as a <base> for the whole stage ?
> env="" <!-- at least in my profiles, add is the common case -->
> envclearto=<no default> <!-- and total reset rare -->
Or maybe a flag to say clear the env space before setting it to env.
> user=<user running the tool>
> chroot=<no default>
> role|class|etc.= <!-- maybe something like this for *build people
> who just _have_ surround their elements with
> an extra layer ;) <ducks/> -->
> > Still one problem, specifying more than one env variable. A
> > character works in something like $PATH 'cos that character can
> > appear in what it is separating. Everyones mission should they
> > to accept it is to think of how to separate arbitrary env var
> > that can conceivably contain anything, while staying within the
> > of legal XML. I'm off to the pub :)
> ~ $ cd var/tmp/
> ~/var/tmp $ echo 'echo $FOO $BAR' > echovar
> ~/var/tmp $ FOO="-march=i986 -cpu=i986" BAR="-O9 $FOO -pipe" bash
> -march=i986 -cpu=i986 -O9 -march=i986 -cpu=i986 -pipe
> ~/var/tmp $ FOO="-march=i986 -cpu=i986" BAR='-O9 $FOO -pipe' bash
> -march=i986 -cpu=i986 -O9 $FOO -pipe
> ~/var/tmp $ rm echovar
> ~/var/tmp $
> So maybe:
> <stage env="FOO="-march=i986 -cpu=i986" BAR="-O9 $FOO
> Would make the life of real parser writers difficult, but they'll have
> trouble anyway because they'll need to handle PATH=$PATH:/bar (won't
> they), and everyone who just passes this stuff off to bash will have
> to problems.
Sigh, pass the regex manual. This is doable, an utter pig but doable.
Maybe it would be best to break some of this up into elements, like we
have <setenv> now but as a specific child to <stage> ? Might even be
better to break out some of the oher attribs into elements too. But as
a concept this is looking better and better.
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