On 24.08.2010, at 05:32, Andreas Raab 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).

I was thinking to add a specific list of known unloaded packages. Only those would be skipped when updating.

> 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.

True. I'm just saying that by declaring a package unloadable, we assert it is dependency-clean.

> 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.
> 
> Cheers,
>  - Andreas

I agree, but my point was slightly different ;)

Manually re-ordering the update map is just a work-around for not being able to update multiple packages together. If we could, the order would not matter for moving classes/methods around.

But that shouldn't affect the unloadable packages because, by definition, there are no dependencies from the core packages to them. So they could go to the end of the update list, and be ordered in a way to allow reloading.

What I'm saying is that unless one is trying to move things between the unloadable packages, I see no reason to not have them in loadable order.

- Bert -