1 |
Alexis Ballier schrieb: |
2 |
> On Wed, 27 Feb 2013 18:10:30 +0100 |
3 |
> hasufell <hasufell@g.o> wrote: |
4 |
> |
5 |
>> The other thing is: |
6 |
>> We still have the conflict with eclass-solution vs PM-solution |
7 |
>> (multilib-portage) and I propose not to convert ANYTHING else until |
8 |
>> that conflict is solved, even if it means a council vote (that's what |
9 |
>> I actually think makes sense here). |
10 |
>> I understand both sides and somehow find it appealing to have a |
11 |
>> quicker solution, but since this could damage years of work on a |
12 |
>> portage fork I think we should slow down here. |
13 |
> |
14 |
> except there _has_ been a discussion: |
15 |
> http://article.gmane.org/gmane.linux.gentoo.devel/80330 |
16 |
> |
17 |
> where, at least for me, it appeared that the eclass solution was the |
18 |
> right way and portage-multilib had its defects that could not be solved |
19 |
> without such an eclass solution. |
20 |
> Long story short: portage-multilib does not handle deps needing |
21 |
> multilib and deps not needing them. Only packages maintainers know |
22 |
> that, you cannot guess it at the PM level. Doing unpack twice, while |
23 |
> bearable, is also suboptimal. portage-multilib already disables its |
24 |
> multilib support for multilib-enabled packages, thus there is not even |
25 |
> a conflict there. |
26 |
|
27 |
So you discussed with mgorny (who does not like multilib-portage) and |
28 |
not me and then assume that all details have been written in there? :-) |
29 |
|
30 |
> |
31 |
> The lack of answer on my reply |
32 |
> ( http://article.gmane.org/gmane.linux.gentoo.devel/82740 ) made me |
33 |
> think that the main portage-multilib developer was agreeing with that. |
34 |
|
35 |
Feel free to write my name here ;-) |
36 |
|
37 |
And it seems more likely i just missed that mail, i did not |
38 |
intentionally ignore it. |
39 |
|
40 |
Anyway, in short: the current implementation does add dependencies so |
41 |
that all dependencies need the same ABIs enabled as the package you |
42 |
want. If we move the features into a future EAPI, we can of course drop |
43 |
this and leave the dependency part to the ebuild maintainer. |
44 |
|
45 |
> |
46 |
> On the other hand, Michal has been doing the work and got things done |
47 |
> when portage-multilib has never reached mainline after several years |
48 |
> of development. So, while breaking the tree like the freetype case is |
49 |
> really bad, please do not use this for killing his efforts, esp. when |
50 |
> it is now masked. |
51 |
|
52 |
If you did not know it: anyone can add an eclass, while adding new |
53 |
features via package manager requires a new EAPI. |
54 |
I have written about it on this list for many months, if not years. And |
55 |
every time i solved a request, a new one was raised. And you want to |
56 |
blaim me for multilib-portage not reaching the main tree? |
57 |
|
58 |
|
59 |
Anyway, if there is a sane and easy to use eclass created, which does |
60 |
just multilib and does it properly for all multilib arches also |
61 |
supporting per ABI headers and binaries, i am not opposed against it. |
62 |
|
63 |
I just see issues the way a work-in-progress is pushed into the main |
64 |
tree without prior discussion and additional hacks for issues (freetype |
65 |
headers) forcing other devs to do more work instead of asking for |
66 |
another solution not needing any additional work for depending packages. |
67 |
|
68 |
-- |
69 |
|
70 |
Thomas Sachau |
71 |
Gentoo Linux Developer |