On Mon, Aug 23, 2010 at 8:32 PM, Andreas Raab <andreas.raab at gmx.de> wrote:

> On 8/23/2010 4:53 PM, Bert Freudenberg wrote:
>
>> On 24.08.2010, at 01:44, Levente Uzonyi wrote:
>>
>>> But that doesn't work. For example 311Deprecated depends on Traits, but
>>> Traits is at the end of the list while 311Deprecated is the first non-dummy
>>> package.
>>>
>>
>> Then, obviously, the update map is wrong :)
>>
>
> No, it's not. The update map isn't ordered to allow reloading all the
> packages after they've been unloaded. The update is ordered to allow loading
> all the updates *after the previous update map*. In fact, it can and does
> happen that it switches the ordering of two packages between updates. For
> example, consider moving class Process from Kernel to System. To do this you
> would need the System package to be loaded before the Kernel. But if you
> would load these from first principles, almost certainly you would load
> Kernel before System.
>
> So the order in the update map is fairly irrelevant for the order which you
> would use to load all these packages from first principles. The update map
> simply cannot be used for this purpose.
>
> The real question here is if we should allow updating a subset of packages
> simply by skipping over the packages you haven't present in your image? This
> could be done but would come at the price that we could no longer add new
> "required" packages and let people fetch them automatically (because they
> wouldn't be present in the image they would not be loaded).
>
> In addition, allowing to update subsets would require us to be *much* more
> careful with changing package dependencies - as you can see from the failing
> package dependency tests in the current trunk the dependencies *do* change
> but if we want to allow updating subsets then we have to be "dependency
> clean" in every single update.
>
> The latter is really the reason why I'm not in favor of allowing this.
> Right now we have a solution that basically says when you update
> incrementally, you update an image with all the packages present which keeps
> it nice and simple. At the release points, we spend the additional time to
> make sure all the dependencies are in the right place and we can unload
> things but we don't have to worry about accidentally introducing a
> dependency in the middle and getting angry messages from people whose system
> we broke since they only update a subset of the packages.
>
> Makes sense? If not, then let's discuss ways in which we can improve
> things.
>

I always appreciated the 95% rule, a.k.a. don't let the perfect be the enemy
of the good.  Right now if one removes all packages and updates one gets an
ugly mess one can wade through with the debugger.  If one were to simply
skip the packages not in one's image one could certainly get to a point that
might miss a required package, but one could also update without wading
through the mess, without having to go through the remove unloadable
packages step and without having to go through whatever other steps one had
gone through to produce a finished image.

E.g. take my OS Cog VMMaker image which has been derived from an unload step
to be nice to svn users; the image is half the size of the normal one.  It's
a mild pain to build, loading packages, adding workspaces and repositories
etc.  Yes I could automate all this but it would be much nicer to build it
once and periodically update it.  I don't care if it misses some required
package; I can deal with that issue when I get to it.  But not being able to
update without wading through mud is, to put it mildly, a downer.


>
> Cheers,
>  - Andreas
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100824/505324e1/attachment.htm