1 |
On 02/27/2013 06:58 PM, Alexis Ballier wrote: |
2 |
> |
3 |
>> The other thing is: |
4 |
>> We still have the conflict with eclass-solution vs PM-solution |
5 |
>> (multilib-portage) and I propose not to convert ANYTHING else until |
6 |
>> that conflict is solved, even if it means a council vote (that's what |
7 |
>> I actually think makes sense here). |
8 |
>> I understand both sides and somehow find it appealing to have a |
9 |
>> quicker solution, but since this could damage years of work on a |
10 |
>> portage fork I think we should slow down here. |
11 |
> |
12 |
> except there _has_ been a discussion: |
13 |
> http://article.gmane.org/gmane.linux.gentoo.devel/80330 |
14 |
> |
15 |
> where, at least for me, it appeared that the eclass solution was the |
16 |
> right way and portage-multilib had its defects that could not be solved |
17 |
> without such an eclass solution. |
18 |
|
19 |
I don't even know multilib-portage (think is this way around) that |
20 |
detailed myself, but Tommy[D] claims that some of those problems will be |
21 |
solved in EAPI=6 and that he is willing to work on the spec. |
22 |
|
23 |
The reason I bring this up again is that there was a strong argument |
24 |
yesterday in #gentoo-dev, so it seems the situation is NOT clear. |
25 |
|
26 |
|
27 |
> Long story short: portage-multilib does not handle deps needing |
28 |
> multilib and deps not needing them. Only packages maintainers know |
29 |
> that, you cannot guess it at the PM level. Doing unpack twice, while |
30 |
> bearable, is also suboptimal. portage-multilib already disables its |
31 |
> multilib support for multilib-enabled packages, thus there is not even |
32 |
> a conflict there. |
33 |
> |
34 |
|
35 |
It still does not make sense to work in two different directions, imo. I |
36 |
was supporting the eclass idea myself by proposing |
37 |
autotools-multilib-minimal.eclass, but I think this should be voted on, |
38 |
so we don't duplicate work. |