| 1 |
"Santiago M. Mola" <coldwind@g.o> said: |
| 2 |
> On Sat, Apr 4, 2009 at 2:59 PM, Thomas Sachau <tommy@g.o> wrote: |
| 3 |
> > Hi folks, |
| 4 |
> > |
| 5 |
> > |
| 6 |
> > i would like to hear about other opinions about real multilib support |
| 7 |
> > within our tree and package managers. From what i know, there are |
| 8 |
> > mainly 2 different ideas: |
| 9 |
> |
| 10 |
> The proposals are not exactly these. |
| 11 |
> |
| 12 |
> 1. Make package managers multilib-aware [1][2]. |
| 13 |
> |
| 14 |
> Package managers would be able to have a default ABI (say, x86_64) and |
| 15 |
> optional ones (x86). Everything would be built for the default ABI, |
| 16 |
> and the package manager could build things for optional ABIs on an as |
| 17 |
> needed basis. That is, if I install a 32bit binary package, the |
| 18 |
> package manager will build any 32bit libraries it needs automatically. |
| 19 |
> |
| 20 |
> Package managers will have to expose to ebuilds a mechanism to iterate |
| 21 |
> over enabled ABIs and build anything needed for each one. |
| 22 |
> |
| 23 |
> Pros: |
| 24 |
> - Any package can be made multilib aware, getting rid of the emul-* |
| 25 |
> packages. - 32bit libraries are built automatically and as needed. |
| 26 |
> - This system can be extended to support other kind of ABIs. Making it |
| 27 |
> possible to build packages for various versions of Python/GHC/etc |
| 28 |
> simultaneously. |
| 29 |
> |
| 30 |
> Cons: |
| 31 |
> - Needs to be implemented on the PM-side and needs a new EAPI. |
| 32 |
> |
| 33 |
> 2. Implement multilib on the ebuild level. |
| 34 |
> |
| 35 |
> For amd64, this would mean adding a 'lib32' USE flag to every multilib |
| 36 |
> ebuild, and use it for building 32bit libs as needed. |
| 37 |
> |
| 38 |
> Pros: |
| 39 |
> - Any package can be made multilib aware, getting rid of the emul-* |
| 40 |
> packages. - Doesn't need PM changes. |
| 41 |
> |
| 42 |
> Cons: |
| 43 |
> - Package manager won't be multilib-aware, so it won't be able to |
| 44 |
> build 32bit libraries automatically and as needed. |
| 45 |
> - Users will have to enable 'lib32' USE flag manually for every |
| 46 |
> library they needed. Enabling 'lib32' by default is not an option |
| 47 |
> since it would build tons of unneeded 32bit libraries for every user. |
| 48 |
|
| 49 |
reading the proposals so far, it sounds to me that only the one that |
| 50 |
requires pms changes would qualify as 'real multilib support'. |
| 51 |
|
| 52 |
> |
| 53 |
> |
| 54 |
> [1] http://dev.exherbo.org/~pioto/abi-ideas.html |
| 55 |
> [2] http://bugs.gentoo.org/show_bug.cgi?id=145737 |
| 56 |
> |
| 57 |
> Regards, |
Archives