About MC for managing the image
avi.bryant at gmail.com
Sun Sep 18 20:07:59 UTC 2005
On Sep 18, 2005, at 12:53 PM, Andreas Raab wrote:
>> I do think that using a Squeak package with dependencies, or
>> alternatively just changing a Configuration to have a load
>> strategy more like a package with dependencies, would be a good
>> idea. When I recently tried updating a 3.9a image through a few
>> configuration steps, it was bad enough that it took as long as it
>> did, but it was awful that it stopped to ask me about loading
>> over a modified package many times during the process - so I
>> couldn't just walk away. This wouldn't happen if MC's multi-
>> package-load mechanism were used instead of explicit ordering.
>> It would also mean you wouldn't (usually) have to think about
>> package ordering yourself. So it should speed up the process for
> Please say more about this, since it's been a while that I have
> used dependencies in MC at all. About load strategies: I don't know
> what strategy MC uses but unless it gets this right every single
> time (which I doubt) having configurations is vastly advantageous.
> Usually, I have a "master configuration" (for a project like Tweak)
> which lists the fifty or so packages in what I consider "load
> order", e.g., a unique order for loading the packages that includes
> eventual dependencies. If I post a new configuration I simply
> "update" the old oonfiguration from either image or packages and
> post it. It's a very simple process but if there's any need I can
> re-order the packages for that specific post.
Let's say I have two packages, A and B. I have a new configuration
in which these two packages have exchanged methods: one method from A
has moved to B, and one method from B has moved to A. I try to load
that configuration. Either load order is equivalent, but let's say
that we've specified that the order is A, B.
What happens is this: first A is loaded, taking one method from B and
losing one method itself. Because it took a method from B, B is now
marked as being modified. Next, B is loaded, but it has a modified
flag, and so the user is asked whether it's ok to ignore those
modifications. This is confusing, since the user never has modified
B. It's also irritating because the load can't proceed unsupervised.
Ok, now a more complicated scenario: A has added a Foo class and a
BarSub class. B has added a FooSub class and a Bar class. FooSub is
a subclass of Foo, and BarSub is a subclass of Bar. This is
admittedly contrived, and arguably bad design, but there's no
sequential load order that will work for these two packages.
Both of these cases are solved by simply asking MC to load or merge
the two packages together, rather than asking it to load them
sequentially. The load strategy it uses is very simple: a superclass
always needs to be loaded before its subclasses, and a class always
needs to be loaded before its methods. Additions are always done
before removals, and removals are done with the inverse rules (first
remove methods, then classes, then superclasses).
What you don't get to do in that case is specify anything about the
load order yourself. I think the cases where specifying this is
necessary are going to be very rare, but certainly they will happen.
That's what the update stream is useful for: simply put two
configurations in (one of them, maybe, with only a single package) to
ensure that loads happen in the correct sequence. This should only
be needed for delicate migrations, I don't think it should ever be
needed for every time a group of packages is loaded together.
More information about the Packages