I understend that in certain settings installing xulrunner is not a good option. However dev-lang/spidermonkey do collide with net-libs/xulrunner and hence cause troubles on desktop settings. Possibly virtual package would be an option.
I don't understand how spidermonkey and xulrunner collide. Can you be more specific? elinks and couchdb are maintained by separate Gentoo developers. Please change the summary to reflect only one package, and file a separate bug for the other.
Please file a new bug report for dev-db/couchdb.
I've just submitted bug #349824 (for couchdb) and bug #349825 (for disallowing parallel installation.
I do not see the point in deping on xulrunner without needing anything more then standalone Javascript. There is no package collision with xulrunner user has something seriously wrong with his setup.
Here is an example of how it messes my box up. If I let dev-lang/spidermonkey-1.9.2.13 install (Its out if the picture here via emerge -C now), then vuze breaks. It gets an exception in libmozjs.so which is provided by both xulrunner and spidermonkey. The xulrunner version works, spidermonkey's does not...
Closing as invalid as the conclusion of bug #349825 seems to be that there is in fact no file collision.
(In reply to comment #6) > Closing as invalid as the conclusion of bug #349825 seems to be that there is > in fact no file collision. > Sorry for delay in responding. While the colision is non-existing spidermonkey still breaks programs both in portage (vuze from comment #5) as in out of portage (gjs) so it may still be benefitial if users could install elinks against xulrunner.
(In reply to comment #7) > (In reply to comment #6) > Sorry for delay in responding. While the colision is non-existing spidermonkey > still breaks programs both in portage (vuze from comment #5) as in out of > portage (gjs) so it may still be benefitial if users could install elinks > against xulrunner. If just installing spidermonkey breaks vuze, please file a bug against vuze as this sounds like an issue with that package, which should be fixed.
I just installed xulrunner with =dev-lang/spidermonkey-1.7.0 =www-client/elinks-0.12_pre5-r1 installed with FEATURES=collision-protect and I did not detect any problems. # emerge -q net-libs/xulrunner >>> Verifying ebuild manifests >>> Emerging (1 of 1) net-libs/xulrunner-1.9.2.13 >>> Installing (1 of 1) net-libs/xulrunner-1.9.2.13 >>> Recording net-libs/xulrunner in "world" favorites file... * GNU info directory index is up-to-date. And, I just re-emerged dev-lang/spidermonkey and still no problems with the install xulrunner package. I recommend closing this bug and request the filer to file a log file and/or reword the summary of this bug to not include elinks/spidermonkey. I'm guessing, this bug is more targeted towards vuze and/or vuze.ebuild. Although I am seeing patches on the net for compiling elinks against xulrunner, feel this is something that should be dealt with upstream unless somebody submits a patch. (I doubt many ELinks users will want to compile a heavy package such as xulrunner along side their slim sleak ELinks browser. <shrugs>)
I'm not sure if this is related or a different bug, but spidermonkey 1.9.2.15 is showing up an upgrade in portage and whenever spidermonkey 1.7.0 is upgraded to 1.9.2.15, it breaks: * Checking dynamic linking consistency [ 9% ] * broken /usr/bin/elinks (requires libjs.so) [ 47% ] * broken /usr/lib64/gpac/gm_gpac_js.so (requires libjs.so) [ 64% ] * broken /usr/lib64/libgpac-0.4.5.so (requires libjs.so) [ 100% ] revdep-rebuild then suggests the solution is a downgrade of spidermonkey, and recompiling: Calculating dependencies... done! [ebuild UD] dev-lang/spidermonkey-1.7.0 [1.9.2.15] [ebuild N ] dev-libs/boehm-gc-7.1-r1 USE="threads -nocxx" [ebuild R ] media-video/gpac-0.4.5-r1 [ebuild U ] www-client/elinks-0.12_pre5-r1 [0.11.7] USE="mouse%* samba%*" so, something somewhere is not listing dependencies properly (if they were, we'd have a blocked upgrade). Note that I didn't realize this issue was occurring until I noticed that I had for some reason been constantly upgrading spidermonkey for quite awhile: Wed Nov 24 11:15:59 2010 >>> dev-lang/spidermonkey-1.7.0 Wed Dec 15 13:28:33 2010 >>> dev-lang/spidermonkey-1.7.0 Wed Mar 30 14:36:31 2011 >>> dev-lang/spidermonkey-1.9.2.15 Wed Mar 30 15:46:57 2011 >>> dev-lang/spidermonkey-1.7.0 Thu Mar 31 02:00:57 2011 >>> dev-lang/spidermonkey-1.9.2.15 Thu Mar 31 11:13:08 2011 >>> dev-lang/spidermonkey-1.7.0 Sat Apr 2 06:36:20 2011 >>> dev-lang/spidermonkey-1.9.2.15 Sat Apr 2 08:02:03 2011 >>> dev-lang/spidermonkey-1.7.0 Sat Apr 2 19:55:24 2011 >>> dev-lang/spidermonkey-1.9.2.15
In ref to Comment #10, elinks depends on <=dev-lang/spidermonkey-1.9 for javascript USE flag. Stabilizing for =dev-lang/spidermonkey-1.9.2.15 just occurred, so this is an elinks specific bug/lacking for support of the newer spidermonkey.
For the reference gjs (from gnome overlay but it probably be in portage soon) blocks spindermonkey depending on xulrunner.
I added a patch to elinks to allow it to compile with spidermonkey-1.9*. I'm closing this as WONTFIX, since elinks doesn't support building against xulrunner by default. Also, there is no file collision between spidermonkey and xulrunner (I have both installed on my system). If having both packages installed breaks some other programs, please file bugs against these programs.
