1 |
On Wed, 27 Feb 2013 22:08:45 +0100 |
2 |
Thomas Sachau <tommy@g.o> wrote: |
3 |
|
4 |
> Alexis Ballier schrieb: |
5 |
> > On Wed, 27 Feb 2013 18:10:30 +0100 |
6 |
> > hasufell <hasufell@g.o> wrote: |
7 |
> > |
8 |
> >> The other thing is: |
9 |
> >> We still have the conflict with eclass-solution vs PM-solution |
10 |
> >> (multilib-portage) and I propose not to convert ANYTHING else until |
11 |
> >> that conflict is solved, even if it means a council vote (that's what |
12 |
> >> I actually think makes sense here). |
13 |
> >> I understand both sides and somehow find it appealing to have a |
14 |
> >> quicker solution, but since this could damage years of work on a |
15 |
> >> portage fork I think we should slow down here. |
16 |
> > |
17 |
> > except there _has_ been a discussion: |
18 |
> > http://article.gmane.org/gmane.linux.gentoo.devel/80330 |
19 |
> > |
20 |
> > where, at least for me, it appeared that the eclass solution was the |
21 |
> > right way and portage-multilib had its defects that could not be solved |
22 |
> > without such an eclass solution. |
23 |
> > Long story short: portage-multilib does not handle deps needing |
24 |
> > multilib and deps not needing them. Only packages maintainers know |
25 |
> > that, you cannot guess it at the PM level. Doing unpack twice, while |
26 |
> > bearable, is also suboptimal. portage-multilib already disables its |
27 |
> > multilib support for multilib-enabled packages, thus there is not even |
28 |
> > a conflict there. |
29 |
> |
30 |
> So you discussed with mgorny (who does not like multilib-portage) and |
31 |
> not me and then assume that all details have been written in there? :-) |
32 |
|
33 |
You're making this more and more confusing. I don't know if you're |
34 |
doing that intentionally or by accident but please try to make it |
35 |
clearer what multilib-portage can and cannot do rather than keeping it |
36 |
all blurry. |
37 |
|
38 |
> > On the other hand, Michal has been doing the work and got things done |
39 |
> > when portage-multilib has never reached mainline after several years |
40 |
> > of development. So, while breaking the tree like the freetype case is |
41 |
> > really bad, please do not use this for killing his efforts, esp. when |
42 |
> > it is now masked. |
43 |
> |
44 |
> If you did not know it: anyone can add an eclass, while adding new |
45 |
> features via package manager requires a new EAPI. |
46 |
> I have written about it on this list for many months, if not years. And |
47 |
> every time i solved a request, a new one was raised. And you want to |
48 |
> blaim me for multilib-portage not reaching the main tree? |
49 |
|
50 |
You told me yesterday that so far you haven't even listed all |
51 |
the details on how multilib-portage works on the ml. Do you expect us |
52 |
to accept the feature without even having it explained first? |
53 |
|
54 |
> I just see issues the way a work-in-progress is pushed into the main |
55 |
> tree without prior discussion and additional hacks for issues (freetype |
56 |
> headers) forcing other devs to do more work instead of asking for |
57 |
> another solution not needing any additional work for depending packages. |
58 |
|
59 |
Believe it or not, this is a proper solution. Hacking it around does |
60 |
not fix the actual issues. |
61 |
|
62 |
-- |
63 |
Best regards, |
64 |
Michał Górny |