Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 433511 - add multilib support (from portage multilib branch in git) to master branch
Summary: add multilib support (from portage multilib branch in git) to master branch
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Enhancement/Feature Requests (show other bugs)
Hardware: All All
: Normal enhancement with 2 votes (vote)
Assignee: Portage team
Depends on:
Reported: 2012-08-31 09:23 UTC by Vadim A. Misbakh-Soloviov (mva)
Modified: 2016-04-08 16:45 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Vadim A. Misbakh-Soloviov (mva) gentoo-dev 2012-08-31 09:23:49 UTC
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
Comment 1 Alexander E. Patrakov 2012-11-06 06:43:19 UTC
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.
Comment 2 Zac Medico gentoo-dev 2016-04-08 16:45:14 UTC
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.