Can you finally merge multilib branch to master in portage git? :) Also, it will be nice to start work on rewriting ebuild to support this multilib then. And after all — drop emul-x86 to the hell. Reproducible: Always
I am not a Gentoo developer, but I think that multilib support is better rewritten from scratch instead of being taken from that branch. The branch relies on the following questionable or outright false assumptions resulting in useless inflation of the dependency tree: 1) "If a package is built for multilib, then all its dependencies have to be built for multilib" - false, only the dependencies providing libraries have to be built for multilib. Counterexample: any -9999 package would uselessly pull multilib git or multilib svn according to that logic. 2) "One set of USE flags is good for all ABIs" - false, some USE flags are only affecting the dependencies of 32-bit daemons that are ultimately discarded if only a library is needed. In other words, a use case exists for building a full-featured 64-bit package and a library-only 32-bit one. E.g., I don't want a 32-bit bluez just because I want a 64-bit pulseaudio daemon and a 32-bit libpulse. 3) "A localized change in portage is good enough" - false because of (1) (i.e. someone needs to explicitly mark all "any-abi" dependencies), and unreasonable because someone suddenly needs to audit the whole tree at once for breakages caused by unconditional *.la file removal. This audit is better done incrementally, piece-wise, not tree-wide. 4) "You should be able to build absolutely anything as multilib" - questionable. On amd64, multilib exists mostly as a hack to support proprietary 32-bit-only software and wine. So it is sufficient to be able to build only the dependencies of such software, and doing anything more is a waste of developer and (as explained in (3)) QA resources. 5) "The same approach must handle ARM/MIPS multilib and AMD64 multilib" - questionable (but, to be fair, the branch started historically as amd64-specific). As explained above, the main use case for amd64 multilib is related to proprietary software and wine. On MIPS and other architectures, the use case is probably different (if valid at all - look, the current emul-linux-* hack exists only for amd64), and I don't know it. The currently-pushed alternative is the autotools-multilib eclass by mgorny, and similar eclasses for cmake and other build systems are expected to appear. This approach definitely addresses points (3) and (4) by making multilib-buildability opt-in for each package (by ebuild maintainers), successfully demonstrates that (5) is not really an issue, provides some means to address (1) and does not make (2) impossible. Still, for (1) and (2), someone needs to manually mark the same-ABI dependencies and write support for the "minimal-secondary-abi" builds.
I think we can consider this obsolete, since we have adopted an eclass-based solution. If we add multilib extensions to the package manager, then it will be tied to EAPI and PMS.
