Bill Allombert wrote: > After spending a dozen of hour tracking it, I have the obvious headache, > but also the following: > > 1) debootstrap woody > > 2) Install the following packages: > konqueror aptitude libqt3 libhtml-tree-perl libapt-pkg-perl libft-perl > > 3) point apt at sarge. > > At this point you are between a rock and a hard place: > You can do > 2) aptitude install aptitude, but that remove konqueror and perl > 3) aptitude dist-upgrade, but that remove konqueror > > As for the culprit, my headache does not allow me to investigate more, > but here some clues: In _woody_, > > 1) libqt3 has a circular dependency with libqt3-mt. > 2) libhtml-tree-perl has a circular dependency with libwww-perl.
Well, this might help. I did the same thing as Bill, but then I turned on Debug::pkgProblemResolver. aptitude dist-upgrade gives this output: Starting Starting 2 Investigating libqt3c102-mt Or group remove for libqt3c102-mt Or group remove for libqt3c102-mt Or group remove for libqt3c102-mt Or group remove for libqt3c102-mt Or group remove for libqt3c102-mt Or group remove for libqt3c102-mt Package libqt3c102-mt has broken dep on libqt3-mt Considering libqt3-mt 2 as a solution to libqt3c102-mt 22 Added libqt3-mt to the remove list Investigating perl-modules Package perl-modules has broken dep on libnet-perl Considering libnet-perl 6 as a solution to perl-modules 21 Added libnet-perl to the remove list Fixing perl-modules via remove of libnet-perl Investigating libarts1 Or group remove for libarts1 Or group remove for libarts1 Package libarts1 has broken dep on libqt3c102-mt Considering libqt3c102-mt 22 as a solution to libarts1 13 Holding Back libarts1 rather than change libqt3c102-mt Investigating kdelibs4 Package kdelibs4 has broken dep on libarts1 Considering libarts1 13 as a solution to kdelibs4 10 Holding Back kdelibs4 rather than change libarts1 Investigating kdelibs-bin Package kdelibs-bin has broken dep on kdelibs4 Considering kdelibs4 10 as a solution to kdelibs-bin 8 Holding Back kdelibs-bin rather than change kdelibs4 ... I *think* this is what's going on: (1) For whatever reason, it's figured out that it should try to install libqt3c102-mt. (Probably in DepCache::MarkInstall with AutoInst==true). (2) That causes conflicts. It resolves those by deciding to remove libqt3-mt. (3) For unknown reasons, it thinks libarts1 can't satisfy its dependency on libqt3c102-mt. Huh? Clearly it's making the wrong choice when it holds back libarts1. This is likely to be related to libqt3. How does this possibility sound: * It tries removing libqt3-mt, but decides that it can't, because of libqt3. For some reason, it thinks it's necesary to keeping libqt3, even though it depends on libqt3-mt, which is to be removed. * Having done that, everything else follows. I don't know why it doesn't consider getting rid of libqt3, but the circular dependency may have something to do with it. I wondered if adding a Conflicts: libqt3 to the libqt3c102-mt package would convince apt to do the right thing. So I tried a hack where I edited /var/lib/dpkg/status so that libqt3 had a Conflicts: libqt3c102-mt. This did the trick, so I suspect it would. I know technically they shouldn't need to conflict, but due to the circular dependency in woody and the absence of libqt3(non-c102) in sarge, it would be hard for anyone to have them both installed anyway. So it's a good idea. I suggest an upload of qt-x11-free adding that Conflicts. It's sort of horrible to have to upload something that large for a change that tiny, but there you are. --- Now, apt-get dist-upgrade will always try to remove perl as well as KDE; aptitude dist-upgrade manages to hold on to perl, for unknown reasons. (I haven't looked into the extra work done by aptitude, but it seems to make a difference in this case.) It's worth noting that the APT pkgProblemResolver does very little to perl in the aptitude case: Investigating perl-modules Package perl-modules has broken dep on libnet-perl Considering libnet-perl 6 as a solution to perl-modules 21 Added libnet-perl to the remove list Fixing perl-modules via remove of libnet-perl It does much more in the apt-get case: Investigating perl Package perl has broken dep on libterm-readline-perl-perl Considering libterm-readline-perl-perl 0 as a solution to perl 40 Removing perl rather than change libterm-readline-perl-perl ... and it goes downhill from there. This is the same problem line which occurs with "aptitude install aptitude". Doing a little code tracking, this occurs in the Resolve routine in a particular place and must (for the reversed scores to give this result) be under this condition (which I don't understand): (Cache[Start] & pkgDepCache::DepNow) == 0 Under this condition low-score items can push out high-score items, and I don't get why. :-) Anyway, what apt is doing with perl here is clearly wrong behavior, since libterm-readline-perl-perl didn't even exist in woody, and doesn't conflict with (new) perl. What the heck is apt thinking? I'm wondering if there's a genuine APT bug hiding here somewhere. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
