When a package "need" mozilla-firefox (which is often because of a USE flag, for instance nsplugin), it will always try to install www-client/mozilla-firefox even though www-client/mozilla-firefox-bin is installed! Reproducible: Always Steps to Reproduce: 1. For instance, I want to install the mplayer plug-in. 2. I run: MarmotBougeotte portage # emerge -vp mplayerplug-in These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild N ] www-client/mozilla-firefox-2.0.0.6 USE="ipv6 -bindist -debug -filepicker -gnome -java -mozdevelop -moznopango -restrict-javascript -xforms -xinerama -xprint" LINGUAS="fr -af -ar -be -bg -ca -cs -da -de -el -en_GB -es -es_AR -es_ES -eu -fi -fy -fy_NL -ga -ga_IE -gu -gu_IN -he -hu -it -ja -ka -ko -ku -lt -mk -mn -nb -nb_NO -nl -nn -nn_NO -pa -pa_IN -pl -pt -pt_BR -pt_PT -ro -ru -sk -sl -sv -sv_SE -tr -zh -zh_CN -zh_TW" 36,547 kB [ebuild N ] net-www/mplayerplug-in-3.45 USE="nls -divx -gmedia -gtk (-mplayer-bin) -quicktime -realmedia -wmp" LINGUAS="fr -da -de -en_US -es -hu -it -ja -ko -nb -nl -pl -pt_BR -ru -se -zh_CN" 223 kB Total: 2 packages (2 new), Size of downloads: 36,770 kB Actual Results: As one see, it will try to install the non-binary version, although the binary one is installed! So what if I want to install the mplayer plugin (or others) but for using them with the binary package? (I don't need 2 versions of firefox installed) Expected Results: www-client/mozilla-firefox-bin should be matching the same dependency as www-client/mozilla-firefox. I guess that portage has the functionnality that several packages can "provide" the same dependency? This happens often that several programs have the same function and a common interface in the Free Software world...
*** This bug has been marked as a duplicate of bug 160857 ***
I read why the bug160857 marked as duplicate of this one has been closed: apparently vlc (in the duplicate) or other package (here mplayer-plugin) may need some file providden by the sourced package, not available in the binary one, in order to compile themselves as plugins. That's all fine... if portage was just downloading the files, but without compiling firefox. I had compiled ff once or twice. And this is long... Why I stopped to do so is to stop waiting so long (and having my laptop working so hard) each time I wanted to upgrade FF. Binary FF is all fine for me. So what portage should be able to do here, is having a feature telling "this package is only needed for files, not for compiling if some other equivalent package (the firefox-bin here) is already installed"... If you can agree here, then this bug could be transformed in an enhancement for portage.
You CANNOT compile anything against -bin; it lacks headers and other stuff. End of story, please stop reopening this bug. *** This bug has been marked as a duplicate of bug 160857 ***
And no, portage has zero knowledge of package internals, there's no way to say 'this package is only needed for files', it needs to be installed -> you need to compile and emerge it via the provided ebuild.
Ok. I won't reopen it, though you don't have to get so angry. I reopened only once because I try to understand the problem here. What I proposed was not that portage should have any "magical" knowledge of internal package. But the contributor of these packages have this knowledge. And these ones can make rules for ebuilds (that's how they are done anyway. It is already not portage who know magically what use flag and dependencies to apply for an ebuild, as far as I know). So if such a new rule was doable, it would be good in order to avoid a clearly (for me and many people) unecessary compilation. I mean: after all, most other distribution are binary distri and people on these distros are able to build plugin for FF to be working with their binary FF. And I don't only speak of already built plugins, but also of real plugin's build for binary FF. Anyway maybe you won't even read my comment now that this ticket is closed. I was used to be more nicely treated in the Gentoo's community. If I post this kind of ticket, this is not to annoy anyone. This is also to help because I think this portage's behaviour can be improved, for the sake of Gentoo's quality. And I am always opened for discussion.
(In reply to comment #5) > What I proposed was not that portage should have any "magical" knowledge of > internal package. But the contributor of these packages have this knowledge. We are not going to split firefox and maintain firefox-headers, firefox-libs and similar ebuilds, no time for that really. Sorry.
