RDEPED="firefox? ( >=www-client/mozilla-firefox-1.0.6 !>=www-client/mozilla-firefox-1.5 ) This is wrong. Blockers do not exist to restrict dependencies, they are only for packages that cannot coexist. While it might be temting to abuse them to emulate ranged dependencies this is not acceptable. In this case the proper workaround would be RDEPEND="firefox? ( =www-client/mozilla-firefox-1.0* )" or a similar || construct.
Except that =www-client/mozilla-firefox-1.0* without any block causes perpetual upgrade/downgrade cycles when using --deep.
Created attachment 82080 [details, diff] firefox 1.5 support Why not fixing it properly? ;)
Forgot to say: dev-util/eclipse-sdk should be fixed likewise. Any other packages to fix?
in reply to Hanno Meyer-Thurow it does not work this way, have you tested the libs after the successful build with ldd -r FYI https://bugs.eclipse.org/bugs/show_bug.cgi?id=126648 and especially this comment https://bugs.eclipse.org/bugs/show_bug.cgi?id=126648#c2 to simplify - it does not work and while at this why not using the pkg-config files, which is way better
I did not have closer look on that issue before. It compiles then, azureus and eclipse-sdk run. But, well, I do not know if these applications use that library. I guess not. Why not using pkg-config? Lazy me did not fix it yet. Although, I thought about it. You are free to do so. I got other things to work on. And my diff is wrong anyway. ;)
in fact I would have made the same mistake, was I not in badly need for the embeded browser widget :) they also need the MOZILLA_FIVE_HOME to be set in order for it to work, so even using the rpath trick from the pkg-config will not really help for it to work reliably :( I mean starting the external browser (for example epiphany) after using the internal browser will segfault epiphany function setup-mozilla-opts() { if use mozilla; then gecko=mozilla einfo "Compiling against www-client/mozilla" else gecko=firefox einfo "Compiling against www-client/mozilla-firefox" fi export GECKO_SDK=`pkg-config --variable=libdir ${gecko}-gtkmozembed` export GECKO_INCLUDES=`pkg-config --cflags ${gecko}-gtkmozembed` export GECKO_LIBS=`pkg-config --libs ${gecko}-gtkmozembed` } that's what I use, but sadly it does not work with firefox-1.5
P.S. In fact instead of the blocker it would be more appropriate to check the firefox version and if it is 1.5 to simply warn the user that the embedable widget will not be built.
So when will we see any progress come into portage about this? Currently, if you have both Azereus (which needs swt) and firefox on a ~x86 system, your stuck with the block. Highly annoying ...
(In reply to comment #8) > So when will we see any progress come into portage about this? Currently, if > you have both Azereus (which needs swt) and firefox on a ~x86 system, your > stuck with the block. Highly annoying ... Ditto for amd64. Based on comments in the blackdown-jdk ebuild, I was able to clear the block by enabling the "nsplugin" USE flag, and disable "browserplugin" and "mozilla". Enabling or disabling "firefox" doesn't seem to matter for swt (but enabled is better since I'm using Firefox.) These changes will probably affect other packages, though; the real issue seems to be reconciling these overlapping USE flags.
Dropped the invalid block. As stated earlier, the new version drops support for all mozilla backends except gecko-sdk (soon to be changed to xulrunner).
