MongoDB should depend on spidermonkey 1.7.0-r1 which has the unicode USE flag, which mongo appears to require to build. The ebuild fails with an error that I need spidermonkey with USE+unicode, however, 1.7.0-r1 is ~arch and 1.7.0 does not support the unicode use flag. Reproducible: Always Steps to Reproduce: Using an x86 without accepting ~arch, run the following: ACCEPT_KEYWORDS="~x86" emerge -av mongodb # fails USE="unicode" ACCEPT_KEYWORDS="~x86" emerge -av mongodb spidermonkey # wins Actual Results: Noted above Expected Results: Noted above
All dev-db/mongodb ebuilds are currently ~arch so either run ACCEPT_KEYWORDS=~arch or use /etc/portage/package.keywords to keyword dev-lang/spidermonkey for you arch in advance.
I'm not saying it doesn't work with that, but finding that you have to unmask spidermonkey as well is anything but obvious. If you depend on the correct version of spidermonkey, it will at least be flagged that you need to unmask spidermonkey rather than leaving you to figure it out.
Upon consultation with my friend James here, the problem as he sees it appears to be as follows: 1. Running 'x86'. 2. Wanting 'mongodb'. 3. Sees mongodb is ~ masked and unmasks it. 4. Trys Installing mongodb. 5. Portage fubars saying "You need spidermonkey with +unicode" 6. James sets 'unicode' in package.use 7. James repeats step 4 and sees message 5 again. 8. James files a bug report. To me, the issue is mostly portage's fault, in that the error given is not clear or concise with regard to how to proceed next. Granted one with much experience with this sort of thing has a knack/instinct for what to do next, but its not very friendly the first time. A temporary remedy for this solution would be depending on the higher ( masked ) version of spider-monkey, which will hopefully return a more understandable error about higher versions of spider-monkey being masked. The only caveat to doing this however, is if somebody plans to one day backport the unicode use-flag support to a spidermonkey that's already in 'x86' and that version *might* be outside that same "minimum" version that one would use to force the aforementioned explosion. Hope this helps.
I filed the bugreport because after successfully managing to install the ~x86 spidermonkey, i noted that it's the only version that carries the useflag. While I personally have gotten it installed, other people who try to limit the number of ~arch packages they install are going to wonder what's going on. The simple short term solution is increasing the dep on spidermonkey, especially considering getting this fixed in portage will probably not happen for a long time.
Alternatively, we can stablereq the -r1 version and this problem gets avoided till another day =). But Ideally, portage should be more explicit about what its doing, =).
That's nothing we should need to fix in the ebuild, I think. Maybe emerge should suggest a version that supports the USE flag. I don't think it does that now.
(In reply to comment #6) > That's nothing we should need to fix in the ebuild, I think. Reasoning: Let's say you have a dep on a SLOTted package with some ebuilds in each SLOT having the required USE flag. The DEPEND would quickly become an ugly dependency hell of different versions and you'd have to keep them updated in every ebuild that DEPENDs on those.
Here's what the message looks like with portage-2.1.8.3 (latest stable): emerge: there are no ebuilds built with USE flags to satisfy "dev-lang/spidermonkey[unicode]". !!! One of the following packages is required to complete your request: - dev-lang/spidermonkey-1.7.0 (Missing IUSE: unicode) (dependency required by "dev-db/mongodb-1.4.4" [ebuild]) (dependency required by "mongodb" [argument]) Maybe we just need to document the "Missing IUSE" message better? I'm not sure if autounmask is able to recognize "Missing IUSE" case, and unmask a newer version as necessary. That's certainly something that we should account for when implementing bug 280097.
We have a depgraph._show_unsatisfied_dep() method that displays this message. It needs to be fixed to show a "masked by: ~x86 keyword" message in this case. Then autoumask will certainly be able to handle it.
This is fixed in git: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=8ed07e3ebab02e760dc499aff4ff95e62f70c208
This is in 2.2_rc68, but I'll leave this bug open until it's in an unmasked version.
This is fixed in 2.1.9.
