Bug 37984

Summary:	Portage dependency and slot handling (specifically kdelibs and qt)
Product:	Gentoo Linux	Reporter:	CJ Kucera <pez>
Component:	New packages	Assignee:	Portage team <dev-portage>
Status:	RESOLVED INVALID
Severity:	normal	CC:	kde
Priority:	High
Version:	unspecified
Hardware:	All
OS:	Linux
Whiteboard:
Package list:		Runtime testing required:	---

Description CJ Kucera 2004-01-12 10:00:31 UTC

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.

Comment 1 CJ Kucera 2004-01-12 20:36:24 UTC

Heh, "sloit handling."  How 'bout I fix that up, eh?

Comment 2 CJ Kucera 2004-01-12 20:37:51 UTC

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.

Comment 3 Caleb Tennis (RETIRED) gentoo-dev

2004-01-13 04:43:27 UTC

Ahh, but that means that in order for someone to install Qt they would have to have KDE already installed.

Comment 4 CJ Kucera 2004-01-13 06:15:41 UTC

Aaah, true.  Heh.  Hadn't thought of that.  :)

Comment 5 Marius Mauch (RETIRED) gentoo-dev

2004-01-14 17:43:07 UTC

!< is very different from >=

Comment 6 CJ Kucera 2004-01-14 20:07:50 UTC

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.