mark.uzumati at virgin.net
Mon Apr 1 14:06:37 PST 2002
On 2002.04.01 22:37 Neven Has wrote:
> On Mon, Apr 01, 2002 at 10:54:11AM -0800, Jesse Tie-Ten-Quee wrote:
> > > I mean, the only thing where it will make a difference, is the
> > > <setenv> (or <environment> inside <stage>). This is because it
> > > make setting the environment a container of that environment. So
> > > every element inside is executed, parser will have to go through
> > > <stage> and _then_ set the environment.
> > > With the way it is now, one can easily skip some <setenv>s and
> > > perhaps execute elements after it, which depend upon it.
> > Uh, skip? What difference is it if it's inside a stage or it has
> > own tags? I don't see how that makes all that much more of a
> > difference.
> For example:
> <setenv> <!-- set the variable -->
> <setenv> <!-- unset the variable -->
> If you want to start executing from <configure>, there is no reason
> <setenv> to be executed first.
> It is totally independent of it, and nothing tells it that <setenv>
> _needs_ to be executed first.
> But if <configure> is _inside_ <setenv>, as its child, it would be
> that it needs it.
> And I'm talking XML-only here, I don't see it as an implementation
> purely a syntax one.
> > I though the point of <stage> is to make it easier to group things.
> > can't support such a change if i can't easily use <stage> like we
> > presently using <build> and so forth... otherwise, it's just making
> > things more complicated then need be. [however, i'll wait untill i
> > a good example before making a judgement on this]
> Actually, the <stage> _would_ be like <*build> elements (containers
> only). But with the variable name and additional feature - a
> to set the environment, change root directory and change user IDs.
> > If you have the time, please do. I've read most of the threads on
> > subject and so many things were said, it's just confusing me at this
> > point. It would probably simplify things overall for everyone too
> > Even just like a portion of chapter 5 or something, to show if off.
> Hm, this is messy. There are too many <stage>s everywhere and soooo
> nesting levels. I find it very hard to read. And I wrote it myself. ;)
> I have added <stage>s wherever <*build> elements used to be. Also,
> "stageInfo" and "packageInfo" are used. I haven't modified other
> I have also attached a quick'n'dirty patch against nALFS-1.0.2,
> as an example of how it would look ("*Info" elements should probably
> be removed from the output). But this is more like "for fun" - we
> shouldn't consider this when talking about syntax.
> Anyway, after writing this, I'm not sure about <stage> any more. :/
> It's hard to see what the stage really is - you have to find a
> then search for name and finally read it. Simple elements that
> themselves (<build>, <chroot> and others) make a profile much easier
I see what you mean, but i still like the idea. Maybe it would improve
readability to have the stage name as an attribute, it would then be
more obviously attached to that particular stage ? Still keep all the
other stuff in <stageinfo>. Or maybe it just shouldn't be a replacement
for the *build stuff, but instead used specifically for modifying the
environment, and i use environment in its broad term, including user
and group as well as variables ?
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