Sarah Jelinek wrote: > Jean McCormack wrote: >> Karen Tung wrote: >>> Hi Jean, >>> >>> In a few places in your message below about requirements from the >>> engine, >>> you mention that the engine should "provide defined points....". >>> Do you mean to say that these stop points would be defined by the >>> engine? >>> I think that it is kinda limiting to have the stop points be defined >>> by the engine. >>> Each installer is different and it might make sense for them to stop >>> at different points. >>> I think it makes more sense for the engine to have the ability to >>> accept the >>> definition of stop points, and be able to stop and resume from those >>> points somehow. >> When talking with Sarah it actually became very blurred where the >> lines are drawn. I believe, >> correct me if I'm wrong Sarah, that the engine redesign will have >> more clear functional blocks. >> Like target discover, target initiation, transfer of bits. Then we >> have more specific code to put into >> these blocks. Those would be the defined points to stop at. > > It is blurred where the lines are drawn. The way I see the engine at > this point is that it provides common functionality used by Caiman > installers. So: > > -target discovery > -target instantiation > -installation of bits > -setup for postinstall tasks > > if we want to stop at any point during these tasks I would think the > engine would have to define what was doable. Otherwise the user would > have undefined results. I think that each of these tasks are stop > points, that is that each of the above are 'atomic' in terms of > defining a task that you can stop before or after. Since DC will be one of the consumer of the engine, there's a need for DC to stop at any random points of the "postinstall tasks". That's what checkpointing and the finalizer engine allows today.
> > Stopping in the middle of say installation of bits doesn't provide > anything that I can see as useful. > Well, for a "regular" installation, that might not be very useful, but for DC, it is certainly very useful. For example, A DC user wants to experiment with constructing an image. The user knows that he/she would need a "base" set of packages. He/she wants to experiment with adding some packages to this base, or subtracting packages from this base. So, the stop/resume/rollback feature would be very useful for this. The user would first install the base set, and then, "play" with any additions or subtractions. Of course they don't want to re-install the base set after their experiment. So, we should be able to checkpoint and resume from after installation of the base set. Thanks, --Karen
