1 |
El mié, 27-02-2013 a las 18:58 +0100, Alexis Ballier escribió: |
2 |
> On Wed, 27 Feb 2013 18:10:30 +0100 |
3 |
> hasufell <hasufell@g.o> wrote: |
4 |
> |
5 |
> > I don't want to start another useless rant here, because I perfectly |
6 |
> > understand the issue with ABI specific headers. |
7 |
> > |
8 |
> > The problem is: |
9 |
> > a) if you break a provider on purpose, then you should feel |
10 |
> > somehow responsible for the consumers and not just dump testing and |
11 |
> > fixing on your fellow devs |
12 |
> > b) just test such things in an overlay first and see it explode, then |
13 |
> > think about it again and ask on dev-ML if other people find it even |
14 |
> > WORTH the hassle |
15 |
> |
16 |
> agreed with that |
17 |
> |
18 |
> > The other thing is: |
19 |
> > We still have the conflict with eclass-solution vs PM-solution |
20 |
> > (multilib-portage) and I propose not to convert ANYTHING else until |
21 |
> > that conflict is solved, even if it means a council vote (that's what |
22 |
> > I actually think makes sense here). |
23 |
> > I understand both sides and somehow find it appealing to have a |
24 |
> > quicker solution, but since this could damage years of work on a |
25 |
> > portage fork I think we should slow down here. |
26 |
> |
27 |
> except there _has_ been a discussion: |
28 |
> http://article.gmane.org/gmane.linux.gentoo.devel/80330 |
29 |
> |
30 |
> where, at least for me, it appeared that the eclass solution was the |
31 |
> right way and portage-multilib had its defects that could not be solved |
32 |
> without such an eclass solution. |
33 |
> Long story short: portage-multilib does not handle deps needing |
34 |
> multilib and deps not needing them. Only packages maintainers know |
35 |
> that, you cannot guess it at the PM level. Doing unpack twice, while |
36 |
> bearable, is also suboptimal. portage-multilib already disables its |
37 |
> multilib support for multilib-enabled packages, thus there is not even |
38 |
> a conflict there. |
39 |
> |
40 |
> The lack of answer on my reply |
41 |
> ( http://article.gmane.org/gmane.linux.gentoo.devel/82740 ) made me |
42 |
> think that the main portage-multilib developer was agreeing with that. |
43 |
> |
44 |
> On the other hand, Michal has been doing the work and got things done |
45 |
> when portage-multilib has never reached mainline after several years |
46 |
> of development. So, while breaking the tree like the freetype case is |
47 |
> really bad, please do not use this for killing his efforts, esp. when |
48 |
> it is now masked. |
49 |
> If you want to start another discussion on the subject, then please |
50 |
> make a summary of the previous ones and start it (council will very |
51 |
> likely ask you to do it if you want a vote anyway). If you do not want |
52 |
> to, then please thank Michal for getting things done and finally giving |
53 |
> us a sane multilib support. |
54 |
> |
55 |
> Alexis. |
56 |
> |
57 |
> |
58 |
|
59 |
Personally, I second this Alexis appreciations, I also highly appreciate |
60 |
how Michal is working on getting things done and I doubt he broke the |
61 |
tree on purpose (he has contacted me multiple times to ensure wouldn't |
62 |
be collisions in transition period with emul packages, then, I doubt we |
63 |
can blame on him saying he doesn't discuss things enough). He committed |
64 |
a broken package? Yes, but also masked it soon enough and is working on |
65 |
fixing the problem. |