Unwanted Optimizations

Christoffer Åberg christoffer.aberg at home.se
Fri Apr 5 06:49:31 PST 2002

On Mon, 1 Apr 2002 22:57:05 +0100
Mark Ellis <mark.uzumati at virgin.net> wrote:

> On 2002.04.01 19:54 Jesse Tie-Ten-Quee wrote:
> > 
> > > 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 it's
> > own tags?  I don't see how that makes all that much more of a
> > difference.
> > 
> > I though the point of <stage> is to make it easier to group things.  I
> > can't support such a change if i can't easily use <stage> like we are
> > presently using <build> and so forth... otherwise, it's just making
> > things more complicated then need be.  [however, i'll wait untill i
> > see
> > a good example before making a judgement on this]
> > 
> > > If there are no other volunteers, I'll modify the beginning of LFS
> > > profile, using the ideas mentioned on the list regarding <stage> and
> > > new <package>, so we could have an example and be able to see the
> > > "full picture".
> > 
> > If you have the time, please do.  I've read most of the threads on
> > this
> > subject and so many things were said, it's just confusing me at this
> > point.  It would problaby simplify things overall for everyone too ;)
> > 
> > Even just like a portion of chapter 5 or something, to show if off.
> > 
> Allow me to try, though be nice, i think easter has taken a toll on my 
> brain :) And forgive me if i go into _really_ simplistic mode, i have 
> to get it straight in my own head as i go.
> Currently, <setenv> appears in profiles in a linear way, it gets 
> executed when the parser reaches it, then is forgotten, just as 
> <mkdir>, <copy> etc. so if you have a profile :-
> <package1 />
> <setenv />
> <package2 />
> > package3 />
> if you request execution to start at package2, the setenv is not 
> executed. <stage> replaces the linear model with a kind of "dependency 
> tree" affair, which is probably completely the wrong term to use but i 
> cant think of anything else :) So with :-
> <package1 />
> <stage>
>    <stageinfo>
>      <name>astagename</stage>
>      <setenv>
>        <variable>FOO</variable>
>        <value>bar</value>
>      </setenv>
>    </stageinfo>
>    <package2 />
> </stage>
> <package3 />
> if you start the profile at package2, the parser knows that since 
> package2 is in the <stage> it must use that stage, and hence it sets 
> FOO.
> Similarly, when the parser finishes everything in the stage, it exits 
> it and restores the environment to its previous state, ie without FOO, 
> or whatever FOO was beforehand if anything. package3 therefore does not 
> have to worry about a polluted environment space.
> This would also apply to setting effective user and group, which would 
> also be reset after the stage exits.
> In effect, <stage> elements are never them selves marked "done", 
> "completed", "skip" or whatever else that will show an element as "not 
> to be executed", as long as one of their children is to be run then 
> <stage> is _always_ executed.
> Does that make any sense ? I don't think i explained it particularly 
> well but hopefully someone else can flesh out my yabberings :)
> Hang on, better way of explaining it to any programmers, <stage> is a 
> function call, everything it defines is a local variable, everything 
> hidden by these locals is put on the stack until the function exits, at 
> which point they are popped from the stack. This is in fact exactly the 
> way i would implement it if we go with this idea.
> Mark

I very good summary IMHO. As I've interpreted it, the point of <stage> has always been this "dependency tree" affair, as you call it. And as such I think it's great and definitely necessary.

However, thinking of the LFS-profile, there are actually more things than su, chroot and setenv which packages depend on. Allow me to explain,

A short outline of building the LFS-system could be:

prepare the new partition
 build some packages static
  build some packages dynamic

All things in the second stage depend on the first stage, and all things in the third stage on the second and first. Maybe it is taking it a bit too far to suggest that pretty much all of chapter 5 should be necessary to do before chapter 6, but small stuff like mounting /mnt/lfs or at least mounting /proc might be pretty easy to implement.

Or maybe it IS possible in the current (or at least the currently discussed <stage>-included) syntex, but I don't think so. Maybe we could add a new element inside <stageinfo> to do this or just allow it to contain commands?

Something like this:

   <name>Chapter 6</name>
     <!-- mounting proc goes here -->
     <!-- su:ing to lfs-user -->
     <!-- chrooting -->

 <!-- all of chapter 6 -->


(though I'm not particularly fond with the name <stageinfo> for this, and would rather have <name> as an attribute). This way one could pause an LFS-installation in the middle of chapter 6 and continue where one left off the following day.

Ok, maybe this isn't very important, but maybe something to consider.


BTW I'm (as you've probably already noticed) new to the list. Hi everybody, thanks for the good work and please excuse my English and other errors to come! :)
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 mailing list