This ebuild (and also the more recent ones but this is the one installed on my machine as an indirect dependency of hplip) depends on x11-lib/qt (without version number). I am in a ~amd64 environment, running the kde-3.5.4. Hence I have qt3 installed and sip is perfectly happy with it. However, each "emerge -uDav world" wants to bring qt4 in. A it is used nowhere, each "emerge --depclean" removes it again. Blocking qt4 in package.mask solved the issue but I would think that including version information in the dependency in the ebuild (sip will build as long as the installed qt version is higher than ...) is the correct solution.
Erm, as long as it works w/ both QT versions, hardcoding any version there is wrong. If you don't want QT4, package.mask it. That's how portage handles slots anywhere.
Hello, I'm experiencing this bug, too, on x86. The problem is that the logic in portage isn't consistent: During merge, "package wants any qt" means "merge the latest qt". But during depclean, "package wants any qt" means "keep at least one satisfying qt package, whether its the latest or not". Personally, I think the depclean logic should be fixed to match the merge logic ("package wants any qt" means "keep the latest"). This is similar to bug #13632, though I'm not familiar with portage internals, so I'm not sure if these issues actually result from the same logic error. I agree that depending on a specific version is not appropriate (dep on qt-3 means qt-4 can't be used - if everyone did that in their ebuilds, and upgrade would never occur, dep on qt-4 is bad because then users don't even have the option of masking qt-4 so that they can have just one qt on their systems). Basically, poke the portage devs. :) Mike
emerge --depclean is broken with slots, see Bug 67179.
