Summary: | emerge should show all choices for unsatisfied || ( x y z ) dependencies | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Keith Gable <ziggy> |
Component: | Core - Dependencies | Assignee: | Portage team <dev-portage> |
Status: | CONFIRMED --- | ||
Severity: | enhancement | CC: | coolsuggies, esigra, Ikonta, jamesbroadhead, kingjon3377, koalinux, mail, pacho, rbu, sam |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: |
https://bugs.gentoo.org/show_bug.cgi?id=327177 https://bugs.gentoo.org/show_bug.cgi?id=669156 https://bugs.gentoo.org/show_bug.cgi?id=791349 |
||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 155723, 288083, 300071, 327177, 246720 | ||
Attachments: | patch to display incorrect || atom |
Description
Keith Gable
2007-01-29 20:27:33 UTC
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. *** |