Just uncovered what I believe to be a logic bug in Portage's handling of dependencies (this is on Portage 2.0.49-r20). The ebuild for x11-libs/qt-3.2.3-r1 has this line in its DEPEND: "!<kde-base/kdelibs-3.1.4" This shouldn't be a problem for me, because I've got kde-base/kdelibs-3.1.4 installed, which fits the dependency. However, in another slot, I've *also* got kde-base/kdelibs-2.2.2-r4 installed, and it appears that the presence of this version of kdelibs is tripping up the installation of qt. I'm pretty sure that I'm no longer using the older kdelibs package, so I just unmerged the older version of kdelibs, and everything went smoothly, but I imagine that something like this could cause problems for other packages as well, and I figured I'd bring it up. Reproducible: Always Steps to Reproduce: 1. 2. 3.
Heh, "sloit handling." How 'bout I fix that up, eh?
Actually, come to think of it, I suppose a much *simpler* fix for this would be just to invert the dependency. Instead of !<kde-base/kdelibs-3.1.4 You'd have >=kde-base/kdelibs-3.1.4 ... and then there's no mucking about inside Portage.
Ahh, but that means that in order for someone to install Qt they would have to have KDE already installed.
Aaah, true. Heh. Hadn't thought of that. :)
!< is very different from >=
Yeah, right, that was only an afterthought on my part... I'd still say that the bug is valid; the dependency seems to only apply within a specific SLOT of kdelibs... Having a differently-slotted kdelibs shouldn't make a difference. Whatever, though, I imagine this doesn't come up too often.
