At the moment, the firefox-bin that is available on ABI_X86=x32 is not multilib and it is the amd64 version. However, the ebuild does not specify the ABI of its dependencies. That leads to the ebuild pulling in only x32 versions of its dependencies, and firefox-bin fails to start due to missing amd64 dependencies. Instead, the ebuild should explicitly state that it requires dependencies with abi_x86_64 for the amd64 version and abi_x86_32 for the x86 version.
So this particular request is going to befall every single binary package in the tree. Although something like: RDEPEND=" x86? ( atom1[abi_x86_32] atom2[abi_x86_32] ... ) amd64? ( atom1[abi_x86_64] atom2[abi_x86_32] ...) " ...would technicaly work, I'm not convinced that it's a good idea to do this in the gentoo repo at this stage, just to support this particular edge-case. I also worry that the dependency tree might still end up with abi_x86_64 holes on an x32-pimary userland, due to packages in @system needing abi_x86_64 without actually being listed as deps. Personally I would be more inclined to p.mask firefox-bin on x32 profiles than try and support this. I will discuss with multilib and mozilla projects to see if we can find a pleasant way to handle this.
I don't really see the problem here. The former approach seems to be the correct one to me. From the viewpoint of an x32 user, -bin packages like this are in no way different than x86-only packages like Skype from the viewpoint of an amd64 user. Skype is handled exactly this way, and it doesn't cause any problems on amd64. Nor x32, for that matter; I have Skype installed on my x32 machine, and it worked out of the box without issues. At least when it comes to firefox-bin, just like with Skype, there's no problem with @system dependencies. I am currently running firefox-bin, without modifying the current ebuild, but simply by manually defining abi_x86_64 for each of its dependencies in package.use, and it works fine. And even if there were any problems with implicit @system dependencies, I would argue that it is a bug in the implicit dependency mechanism itself. If you're suggesting to mask the -bin ebuilds on x32, then that makes absolutely no sense. Like I said, I am currently running firefox-bin on x32 without any issues. Would you mask Skype on amd64 profiles, just because it doesn't support the preferred ABI? And I am quite disappointed to hear this called an "edge-case". x32 is an official ABI in Gentoo, and this is clearly a bug in the ebuild, which is assuming things it should not be assuming. Too often the low popularity of x32 is used as an excuse not to fix obvious multilib bugs. But how does one expect x32 to gain popularity, when there are unsolved multilib bugs?.. In addition, if not solved properly, this will once again become an issue for any other ABI that comes up in the future, which is why proper multilib support is important.
(In reply to Dainius Masiliūnas from comment #2) > I don't really see the problem here. The former approach seems to be the > correct one to me. > > From the viewpoint of an x32 user, -bin packages like this are in no way > different than x86-only packages like Skype from the viewpoint of an amd64 > user. Skype is handled exactly this way, and it doesn't cause any problems > on amd64. Nor x32, for that matter; I have Skype installed on my x32 > machine, and it worked out of the box without issues. > > At least when it comes to firefox-bin, just like with Skype, there's no > problem with @system dependencies. I am currently running firefox-bin, > without modifying the current ebuild, but simply by manually defining > abi_x86_64 for each of its dependencies in package.use, and it works fine. > And even if there were any problems with implicit @system dependencies, I > would argue that it is a bug in the implicit dependency mechanism itself. > > If you're suggesting to mask the -bin ebuilds on x32, then that makes > absolutely no sense. Like I said, I am currently running firefox-bin on x32 > without any issues. Would you mask Skype on amd64 profiles, just because it > doesn't support the preferred ABI? > > And I am quite disappointed to hear this called an "edge-case". x32 is an > official ABI in Gentoo, and this is clearly a bug in the ebuild, which is > assuming things it should not be assuming. Too often the low popularity of > x32 is used as an excuse not to fix obvious multilib bugs. But how does one > expect x32 to gain popularity, when there are unsolved multilib bugs?.. In > addition, if not solved properly, this will once again become an issue for > any other ABI that comes up in the future, which is why proper multilib > support is important. Well first of all, x32 is a "dev" profile, not a stable one, so "official ABI support" is IMO a little strong. Secondly, x32 as I understand it isn't a general-purpose ABI, as it was created for more efficient memory usage in servers. As such, installing firefox-bin along with the necessary suite of x86_64 deps to support it on a server that attempts to be as memory efficient as possible is, IMO, an edge case. I'm not saying that there isn't an issue with the dependencies here, because I agree there are. However this issue will be present in EVERY binary package, not just firefox-bin. Leveraging the eclasses for this doesn't work well, as they can't enforce ${MULTILIB_USEDEP} based on the arch in a static fashion, and I would really prefer not to add ABI_X86 use flags on the binary package itself. I -will- make sure that firefox-bin gets whatever pattern multilib project decides to impose on all binary packages, though, once we decide what that will be.
(In reply to Ian Stakenvicius from comment #3) > Well first of all, x32 is a "dev" profile, not a stable one, so "official > ABI support" is IMO a little strong. Secondly, x32 as I understand it isn't > a general-purpose ABI, as it was created for more efficient memory usage in > servers. As such, installing firefox-bin along with the necessary suite of > x86_64 deps to support it on a server that attempts to be as memory > efficient as possible is, IMO, an edge case. No, it is a general-purpose ABI. One of the use cases it was created for was low-memory netbooks, which is exactly the hardware I'm using here. Web browsers are very important for this use-case, of course. > I'm not saying that there isn't an issue with the dependencies here, because > I agree there are. However this issue will be present in EVERY binary > package, not just firefox-bin. So why not just fix all binary package ebuilds? There isn't an unmanageable amount of those, and the fix is pretty straight-forward.
there are already multilib eclasses to make this simple for you. set the MULTILIB_COMPAT variable, inherit multilib-build and apply [${MULTILIB_USEDEP}] to all the deps. this is how all the other ebuilds in the tree (binary or otherwise) are doing it.
If you feel I have closed your bug and it is still a current issue, please reopen and update it completely. We will not work bugs that have no ebuild in tree any longer or can not be reproduced with a current system. Thank You for your support and understanding The Mozilla Team
Reopened, this is still not resolved in any of the ebuilds. As a workaround for this I had to manually install all dependencies, and of course that broke terribly when Firefox switched to GTK3, because that wasn't compiled for x86_64. So this is very relevant still.
Please feel free to reopen and update any bug report that can be duplicated with current esr builds, 60.x. If you feel your feature needs to be re looked at in any of these bugs reopen and update, please attach patches when appropriate. Thank you Mozilla Team
