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