On Sun, 2011-09-04 at 21:37 +0200, David Kalnischkies wrote: > On Sun, Sep 4, 2011 at 17:42, Christopher Baines <cbaines8@gmail.com> wrote: > > I ran the helpful test case you provided with my code (output attached). > > Have you noticed any way in which dealing with this problem can be > > improved (in my code), it appears to work in the test case, I have not > > tried it in reality? > > What I personally haven't understand is why the ordering starts with > multiarch-support in the partial-upgrade case, while it doesn't in the > dist-upgrade. With unpacking it that early it leaves it in an unpacked > state for an unnecessary "long" time. This a completely valid and good > solution either way through so I didn't bother too much so far. > (So "unnecessary long" is a bit too strong as a word…) The general ordering is done by the pkgOrderList, the ordering and checks I added in the packagemanager can change this enormously, but the order that packages are dealt with is still left to the pkgOrderList. I don’t know specifically why in this case it starts with multiarch-support, I don’t think really considers it much. It does seem a bit strange that Immediate packages are not dealt with first (they are dealt with indiscriminately). What does everyone think, in a apt operation, should packages from essential or important be installed before or after others, or does it not matter? In my opinion, it probably should deal with Immediate packages first. Implementing this would probably involve moving the Immediate code from the packagemanager, to the pkgOrderList, then adding another ordering algorithm to do an initial ordering by priority. > What you could try is creating a squeeze chroot as described earlier in the > bug to reproduce it. Then build 'your' APT in pbuilder for squeeze - > it should install fine then (if your are building in an unstable environment > it is likely that it will depend on a newer version of libstdc++6 than in > squeeze - so technical you are backporting APT to squeeze :) ). > Install this freshly built APT in the chroot and try if it works then. > (I hope it does and did a few tests earlier with copied status files, > but I hadn't the time so far to test it in the proper way) > If all goes well you should be able to do a partial upgrade in your > chroot then - if so we can be sure that your code fixes the problem. Yeah, I will try to try that sometime this week. > If your are feeling like it, there should be way more bugs related to ordering > in the BTS, so if you can (not) reproduce some of them with your code we > could close a bunch (and more) of bugs. :) I will have a look if I some free time, Thanks, Chris
Attachment:
signature.asc
Description: This is a digitally signed message part