I’ve been meaning to write about the 32-bit emulation libraries for a while, with all the problems they come with, included a lot of security problems. The chance come now since last night solar pushed (not yet to the tree though) the new test version of the new emul-linux ebuilds.
The first problem to know of is that at the moment the whole of the set of emulation libraries is a collection of security bugs; I cannot even start to count how many issues there are but for sure there are two for PAM, the two that caused the recent stabilisation of 1.0.4 version. So if you need a system where you count security first, you should not use the multilib profile for AMD64 and the emul-linux libraries. You can still use it without emul-linux for stuff like grub, but that should be it; anything bringing in emul-linux will bring in security-impaired software.
On the other hand, thanks to Daniel’s work on 32-bit userland, it’s likely that building these libraries will start being less of a problem. Some of the fixes are already in, others will go in in time; I fixed Perl and Qt4 last night, the next step is to add a sub-profile for building those libraries.
There is more work that needs to be done though, for instance PulseAudio needs to have a way to disable the whole daemon part and just build the library used by software, which is what you want on both the 32-bit compatibility library list and for daemon-less clients (for instance when you want to just use a remote host to send audio to). These will require some changes in PulseAudio itself and will have, thus, to wait for the new release and probably the one afterwards. I could start working on it already (I would probably be able to get it to work before end of the day) but since I cannot even use it yet it doesn’t make much sense. The problem is that the latest test versions fail nastily on my system, and I was unable to ask Lennart about them, since he’s currently at BOSSA.
Hopefully, one day, the emul-linux libraries wouldn’t be needed at all, and instead we’d be building the packages, in either 32-bit or 64-bit mode, directly as needed. The true multilib support is, currently, one of the most important lacking features of Gentoo; on the other hand, it seems like that what gets discussed for implementation is stuff that has relatively little importance to users, and a lot of importance on “who is right” about implementation details.
Frankly, I really wish we were finally discussing a way to express the difference between same-ABI and any-ABI dependencies between packages, it would be really quite useful especially if the concept of ABI was expanded further to encompass also implementations like Ruby 1.8, Ruby 1.9, JRuby and so on so forth, so that we all could decide whether to build dev-ruby/ruby2ruby for one, the other, or all three together with its dependencies; or whether to install PulseAudio as 64-bit only or both 64-bit and 32-bit.