On Sat, Apr 4, 2009 at 2:59 PM, Thomas Sachau <[email protected]> wrote: > Hi folks, > > > i would like to hear about other opinions about real multilib support within > our tree and package > managers. From what i know, there are mainly 2 different ideas:
The proposals are not exactly these. 1. Make package managers multilib-aware [1][2]. Package managers would be able to have a default ABI (say, x86_64) and optional ones (x86). Everything would be built for the default ABI, and the package manager could build things for optional ABIs on an as needed basis. That is, if I install a 32bit binary package, the package manager will build any 32bit libraries it needs automatically. Package managers will have to expose to ebuilds a mechanism to iterate over enabled ABIs and build anything needed for each one. Pros: - Any package can be made multilib aware, getting rid of the emul-* packages. - 32bit libraries are built automatically and as needed. - This system can be extended to support other kind of ABIs. Making it possible to build packages for various versions of Python/GHC/etc simultaneously. Cons: - Needs to be implemented on the PM-side and needs a new EAPI. 2. Implement multilib on the ebuild level. For amd64, this would mean adding a 'lib32' USE flag to every multilib ebuild, and use it for building 32bit libs as needed. Pros: - Any package can be made multilib aware, getting rid of the emul-* packages. - Doesn't need PM changes. Cons: - Package manager won't be multilib-aware, so it won't be able to build 32bit libraries automatically and as needed. - Users will have to enable 'lib32' USE flag manually for every library they needed. Enabling 'lib32' by default is not an option since it would build tons of unneeded 32bit libraries for every user. [1] http://dev.exherbo.org/~pioto/abi-ideas.html [2] http://bugs.gentoo.org/show_bug.cgi?id=145737 Regards, -- Santiago M. Mola Jabber ID: [email protected]
