| 1 |
On Sunday 05 April 2009 04:18:34 Thomas Sachau wrote: |
| 2 |
> Mike Frysinger schrieb: |
| 3 |
> > On Saturday 04 April 2009 08:59:22 Thomas Sachau wrote: |
| 4 |
> >> i would like to hear about other opinions about real multilib support |
| 5 |
> >> within our tree and package managers. From what i know, there are mainly |
| 6 |
> >> 2 different ideas: |
| 7 |
> >> |
| 8 |
> >> 1. Do the main stuff in the package manager (e.g. if the ARCH is amd64 |
| 9 |
> >> and the package has x86 keyword, the package manager adds a lib32 |
| 10 |
> >> useflag, which would additionally install the 32bit variant of that |
| 11 |
> >> package together with the normal 64bit install). |
| 12 |
> >> |
| 13 |
> >> pro: -much lesser work for package maintainers |
| 14 |
> >> |
| 15 |
> >> contra: -needs addition in PMS and support in the pms, which will need |
| 16 |
> >> some work on their side |
| 17 |
> > |
| 18 |
> > get a *working* implementation first and *then* worry about specing it. |
| 19 |
> > once you have something running with portage, the spec should fall |
| 20 |
> > naturally out. previous multilib methods attempted to spec things out |
| 21 |
> > without any real code and they've all just died. |
| 22 |
> > |
| 23 |
> >> 2. Do the main stuff in the ebuilds themselves (e.g. an additional |
| 24 |
> >> eclass multilib-native.eclass, any ebuild with 32bit support would then |
| 25 |
> >> need adaption and of course inheriting that eclass) |
| 26 |
> > |
| 27 |
> > this is dead end and useless overhead, and i would reject it from any |
| 28 |
> > core package someone would try to merge. |
| 29 |
> |
| 30 |
> From what i got until now, it seems that all answers prefer this option, so |
| 31 |
> i would like to move forward and create some aggreement on how this should |
| 32 |
> look like or some implementation that at least the majority can accept. |
| 33 |
> With this, i would also like to see any changes that need an EAPI to get |
| 34 |
> into EAPI-3. |
| 35 |
> |
| 36 |
> So, anyone already has ideas, specs, some implementation or already working |
| 37 |
> code for this? coldwind linking to |
| 38 |
> http://dev.exherbo.org/~pioto/abi-ideas.html in his post, could this be a |
| 39 |
> base to start with? |
| 40 |
|
| 41 |
that's a laugh. like i said, attempting to spec it out without a real |
| 42 |
implementation will lead to yet another useless pile of crap. there's no |
| 43 |
point in mandating something that is broken, unless of course you simply hate |
| 44 |
people and want to watch them twist. |
| 45 |
-mike |
Archives