Re: A Prisonner of the dependency hell
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.
Reply to: