Created attachment 352024 [details, diff] add multilib-build support For some juniper vpn stuff, I need a 32-bit browser with 32-bit java on my amd64 gentoo machine. (nsplugin-wrapper won't do it!) This can easily be done using multilib-build and the changes are very minor.
Created attachment 355564 [details, diff] patch against firefox-bin-23.0.ebuild Update for firefox-bin-23.0, make use of multilib_is_native_abi.
The problem comes to the profile being shared. This will cause problems later.
(In reply to Jory A. Pratt from comment #2) > The problem comes to the profile being shared. This will cause problems > later. I have done that for a long time, and haven't seen any problems. Can you please give me some details? We could also start the non-native firefox with it's own (new) profile. Beside the fact that the above change also allows to only install a 32-bit firefox on amd64 (USE="-abi_x86_64 abi_x86_32"), which is what I actually needed.
Here's the thing -- after starting a rather heated thread about a similar discussion on the gentoo-dev ML, it has been formalized that the multilib-build stuff is really just for multi-LIB. It's not multi-abi. Because of this, even though setting ABI_X86="32" seems like it would be a nice handy way to obtain 32bit binaries for something, it isn't what the system was designed for and as such isn't something we can support. We -could- support using multilib-build to have the correct abi libraries installed for a 32bit or 64bit firefox-bin, but since only the native-abi binaries are supported anyways, there isn't any point in us doing that in the tree. All of that aside, the mozilla team also doesn't want to support or recommend 32bit firefox in 64bit userspace, so we aren't interested in supporting a profile for this either. Your best bet would probably be to just overlay the firefox-bin ebuild, call it something like firefox-bin32 , and adjust the internals to make sure it doesn't collide with anything else and depend on any necessary 32bit libs it needs.
(In reply to Ian Stakenvicius from comment #4) > Here's the thing -- after starting a rather heated thread about a similar > discussion on the gentoo-dev ML, it has been formalized that the > multilib-build stuff is really just for multi-LIB. It's not multi-abi. > > Because of this, even though setting ABI_X86="32" seems like it would be a > nice handy way to obtain 32bit binaries for something, it isn't what the > system was designed for and as such isn't something we can support. > > We -could- support using multilib-build to have the correct abi libraries > installed for a 32bit or 64bit firefox-bin, but since only the native-abi > binaries are supported anyways, there isn't any point in us doing that in > the tree. I can easily wrap it in multibuild instead of multilib-minimal to make this difference clear. > > > All of that aside, the mozilla team also doesn't want to support or > recommend 32bit firefox in 64bit userspace, so we aren't interested in > supporting a profile for this either. I am happy to join the mozilla team and take care of providing this kind of support. > > Your best bet would probably be to just overlay the firefox-bin ebuild, call > it something like firefox-bin32 , and adjust the internals to make sure it > doesn't collide with anything else and depend on any necessary 32bit libs it > needs. Done already a while ago, it is just annoying to port the changes forward every 2 months.
(In reply to Ian Stakenvicius from comment #4) > Here's the thing -- after starting a rather heated thread about a similar > discussion on the gentoo-dev ML, it has been formalized that the > multilib-build stuff is really just for multi-LIB. It's not multi-abi. To make it more precise, that is the goal of gx86-multilib project: to provide multilib libraries whenever they are necessary to run some stuff that can't be run in native ABI. I think firefox-bin could be bent to this. > Because of this, even though setting ABI_X86="32" seems like it would be a > nice handy way to obtain 32bit binaries for something, it isn't what the > system was designed for and as such isn't something we can support. The eclasses provide a tools for it but require you to decide on the details. Like renaming executables (wrappers in case of Firefox, I think) needs to be done in the ebuild.
(In reply to Christoph Junghans from comment #5) > > Here's the thing -- after starting a rather heated thread about a similar > > discussion on the gentoo-dev ML, it has been formalized that the > > multilib-build stuff is really just for multi-LIB. It's not multi-abi. > > > > Because of this, even though setting ABI_X86="32" seems like it would be a > > nice handy way to obtain 32bit binaries for something, it isn't what the > > system was designed for and as such isn't something we can support. > > > > We -could- support using multilib-build to have the correct abi libraries > > installed for a 32bit or 64bit firefox-bin, but since only the native-abi > > binaries are supported anyways, there isn't any point in us doing that in > > the tree. > I can easily wrap it in multibuild instead of multilib-minimal to make this > difference clear. Following www-plugins/adobe-flash the use flag could be called 32bit.
(In reply to Christoph Junghans from comment #7) > Following www-plugins/adobe-flash the use flag could be called 32bit. Ah, the flag in adobe-flash should be renamed BTW.
Ping@mozilla. As I said above, I would really like to merge this and I am willing to join the mozilla herd to support this feature.
(In reply to Christoph Junghans from comment #9) > Ping@mozilla. As I said above, I would really like to merge this and I am > willing to join the mozilla herd to support this feature. As I alluded to in comment 4 , until such time as multilib-build is actually meant to install 32bit applications (and not just libraries, as it is now), I would vote no on this. Implementation of multilib-build isn't finished yet across the tree, isn't permitted in stable except for a few exceptions, and could very well need some general practice and/or policy changes in the gentoo dev community before it should be permitted to be used in this fashion. In the meantime, there is multilib-portage, which will do what you want without the need for any ebuild changes.
(In reply to Ian Stakenvicius from comment #10) > (In reply to Christoph Junghans from comment #9) > > Ping@mozilla. As I said above, I would really like to merge this and I am > > willing to join the mozilla herd to support this feature. > > As I alluded to in comment 4 , until such time as multilib-build is actually > meant to install 32bit applications (and not just libraries, as it is now), > I would vote no on this. Implementation of multilib-build isn't finished > yet across the tree, isn't permitted in stable except for a few exceptions, > and could very well need some general practice and/or policy changes in the > gentoo dev community before it should be permitted to be used in this > fashion. Ok, firefox-bin has the following lib dependencies: dev-libs/dbus-glib, x11-libs/libXrender(abi_x86_32 done), x11-libs/libXt (abi_x86_32 done), x11-libs/libXmu (abi_x86_32 done), >=x11-libs/gtk+-2.2:2 (bug #489000), >=media-libs/alsa-lib-1.0.16 (abi_x86_32 done). I will take care of the one missing one. www-plugins/adobe-flash and app-emulation/emul-linux-x86-java already provide 32-bit plugins, so basically we are ready to go. So, could we make the 32-bit version of firefox-bin available as a different, 99% identical, ebuild or use a flag (!=abi_x86_32)?
Created attachment 376928 [details, diff] patch against gx86 version Updated version of the patch as all deps got converted.
Created attachment 379154 [details, diff] patch against gx86 version Updated deps.
Created attachment 379156 [details, diff] patch against gx86 version added missing selinux parts.
Created attachment 379334 [details, diff] patch against gx86 version Changes: - ${PN} -> ${MY_PN} = ${PN}$(multilib_is_native_abi || echo -${ABI}) - ${S} -> ${BUILDDIR} Comments: - There is no @NAME@ nor @ICON@ in ${FILESDIR}/${PN}.desktop hence the longer sed sequence. @mozilla: any comments?
@mozilla: ping!
If there are no objections, I will commit this in 10 days!
(In reply to Christoph Junghans from comment #17) > If there are no objections, I will commit this in 10 days! Your gonna do what you want no matter what the mozilla team has told you.
(In reply to Jory A. Pratt from comment #18) > (In reply to Christoph Junghans from comment #17) > > If there are no objections, I will commit this in 10 days! > > Your gonna do what you want no matter what the mozilla team has told you. If somebody objects, I am not going to do anything, but the last comment from the Mozilla team is 9 months ago even though I asked from feedback multiple times. Since then things in multilib moved significantly forward meaning all dependencies have been converted to multilib, we could even wrap the binary automatically if wanted. Concerning your original objection with the shared profile, I have use this feature for nearly a year now, accessing the mozilla profile from the 32bit and 64bit browser (not at the same time though) and didn't find any problem, but I am using chrome for most of my browsing these day anyhow, except for the 2 websites, where I need the 32bit firefox. Also we could leave abi_x86_32 masked for testing for a long while. Additionally I offered to help maintaining the 32bit feature, without any feedback either.
(In reply to Jory A. Pratt from comment #18) > (In reply to Christoph Junghans from comment #17) > > If there are no objections, I will commit this in 10 days! > > Your gonna do what you want no matter what the mozilla team has told you. Either review the patches or give more details about why profile sharing of 32bit and 64bit is not good. This was asked one year ago with still no answer. In addition, there was even a suggestion to avoid profile sharing.
Providing alt-ABI tools via gx86-multilib flags is an abuse of those flags -- in 99% of cases the alt-ABI flags only provide libraries; in fact the only alternative that I'm aware of is adobe-flash and that's due to the fact that the 64bit version occasionally crashes hard on some hardware and so 32bit+ndiswrapper is necessary on those systems. So I don't like it. BUT, I will cede that my opinion doesn't necessarily mean it shouldn't be done. I think i'd be a lot more confortable though if this lived in the mozilla overlay rather than in he tree, though. Thoughts?
(In reply to Ian Stakenvicius from comment #21) > Providing alt-ABI tools via gx86-multilib flags is an abuse of those flags > -- in 99% of cases the alt-ABI flags only provide libraries; in fact the > only alternative that I'm aware of is adobe-flash and that's due to the fact > that the 64bit version occasionally crashes hard on some hardware and so > 32bit+ndiswrapper is necessary on those systems. > > So I don't like it. BUT, I will cede that my opinion doesn't necessarily > mean it shouldn't be done. I think i'd be a lot more confortable though if > this lived in the mozilla overlay rather than in he tree, though. Thoughts? I very much understand this, because I am also a bit unhappy with having to "hide" the 32-bit firefox under the abi_x86_32 use flag, but it is just so easy to re-use the multillib eclasses to get the dependency and the multibuild right. However if this is the problem, it could be rewritten into a simple multibuild.
OK. So mozilla team just had a discussion, and we decided that we just can't support putting this in the tree -- there's too many possible potential issues with profile b0rking to support it for widespread use, and too many people setting ABI_X86="32 64" globally for it to not end up being widespread. We're putting this into the same camp as a www-client/firefox-bin32 package, and setting WONTFIX. For the small amount of demand there is for 32bit firefox on amd64, it can exist as its own package in overlay, or attached to this bug via patches just like PGO support.
Just for the record, this was really unnecessary. I have found that a 64-bit icedtea-web browser plugin can launch a 32-bit JVM.
