The KDE eclass does its -r1 to -r50 searching thing. When it comes up to -r50, it outputs an error that makes absolutely no sense and causes perfectly sane people to lose their mind. My suggestion is when the eclass gets to -r50 and STILL has not found a dependency, it should do something like this: ewarn "Could not locate at least =$pkg_name-$pkg_version. It may be masked or keyworded." (where $pkg_name is the package name you're looking for and $pkg_version is the full minimum version you're looking for) Adding this error will prevent people from going WTF?! and assuming that it's a typo much like I did earlier. The error is still honky. Additionally, it seems as if it's caused by an overlay providing a version of the same package it's trying to resolve dependencies for. So if overlay A says they have _some_ version of kde-base/kdesktop, the eclass outputs the funny message instead of the standard "this package has been masked" message. So outputting that message would be okay as well. FWIW: I searched for an existing bug, and there isn't one under any of the search terms I tried. Forgive me if this is a dupe.
STOP USING BROKEN OVERLAYS AND COMPLAIN TO US.
No; you shouldn't use broken unsupported third-party overlays if you can't deal with the mess caused by them.
The overlays in question do not need to be broken. They need only provide a package. Assume for a second that there was an overlay that kept back versions of KDE packages. So, this overlay provides kdelibs-3.4.0 or something. Because an overlay provides a version of kdelibs at all, this error occurs when the version it wants is ~x86. My proposal is to actually spout an error that will lead the user in the right direction when this happens. Or, put the "this package is masked" error up. Looking at kde-functions.eclass, it looks like making this work would suck, and it totally makes sense for you guys to just say "don't use an overlay", since that solves the problem as well. I still think it should be fixed if someone wants to put the effort in to figure out a way to at least make it easier for the user to figure out what exactly went wrong. Perhaps an einfo before running the loop in the dependency iterator function that says "attempting to pull at least $pkg-$ver-r$num". Since this is a request for feature/enhancement, I'm going to mark it as such.
1/ That message comes from portage, NOT from any kde* eclass 2/ By further messing with the bug you are risking to make developers pretty damn angry. Don't reopen this bug any more.
(In reply to comment #4) > 1/ That message comes from portage, NOT from any kde* eclass Should a bug report for portage be filed then?
Sebastian, it's evident that nobody cares. So, this is the point at which I no longer care. If someone else wants to file a bug on Portage, then go ahead. It's simple. Portage isn't showing the "this package is masked" message when it's calculating dependencies with the kde-functions.eclass and there are overlays involved that provide a version of the package in question (but it doesn't need to be in the range that kde-functions.eclass looks for -- it just needs to be any package with any version whatsoever). Instead, it doesn't find the package, or any range thereof to -r50, and dies. It should instead show "this package is masked" and show all of the valid packages between rN and r50 that are ~x86 or package.mask'ed. A possible test case would be something like this: DEPEND="( =kde-base/kdelibs-3.5.5-r7 || =kde-base/kdelibs-3.5.5-r8 || =kde-base/kdelibs-3.5.5-r9 || =kde-base/kdelibs-3.5.5-r10 || =kde-base/kdelibs-3.5.5-r11 || =kde-base/kdelibs-3.5.5-r50 )" ... but perhaps this would need to be in a function or something. I dunno. I suppose that Gentoo could just disable the overlay feature, since they're unhappy with bugs dealing with the overlay feature, which in a way would fix the bug. It's probably a relatively simple error somewhere though. Leaving as RESOLVED INVALID. Quick fix for the -r50 error is to just look in /usr/portage/category/package and find the next version up from what is installed and ~x86 that version. Or remove the overlays, but that doesn't really solve the problem.
We can make emerge display the entire || ( x y z ) when none of the choices are satisfiable.
Created attachment 108641 [details, diff] patch to display incorrect || atom Here is a patch against HEAD for this.
(In reply to comment #8) > Created an attachment (id=108641) [edit] > patch to display incorrect || atom > > Here is a patch against HEAD for this. > bleh, needs to handle recursion...
+1 for a fix to USE-dependencies. Usecase ==== foo.ebuild: RDEPEND=" || ( bar[a] bar[b] )" USE="-a -b" emerge foo Result ==== Portage will request that bar have USE="a" set, but will ignore the possibility of bar[b].
Comment on attachment 108641 [details, diff] patch to display incorrect || atom Marking patch as obsolete since it doesn't recurse.
*** Bug 578994 has been marked as a duplicate of this bug. ***
*** Bug 754879 has been marked as a duplicate of this bug. ***
