<br><br><div class="gmail_quote">On Mon, Aug 23, 2010 at 8:32 PM, Andreas Raab <span dir="ltr"><<a href="mailto:andreas.raab@gmx.de">andreas.raab@gmx.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On 8/23/2010 4:53 PM, Bert Freudenberg wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
On 24.08.2010, at 01:44, Levente Uzonyi wrote:<br>
</div><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
</blockquote>
<br>
Then, obviously, the update map is wrong :)<br>
</div></blockquote>
<br>
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.<br>
<br>
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.<br>
<br>
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).<br>
<br>
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.<br>
<br>
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.<br>
<br>
Makes sense? If not, then let's discuss ways in which we can improve things.<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Cheers,<br><font color="#888888">
- Andreas<br>
<br>
</font></blockquote></div><br>