Alexis Ballier schrieb: > On Wed, 27 Feb 2013 18:10:30 +0100 > hasufell <[email protected]> wrote: > >> The other thing is: >> We still have the conflict with eclass-solution vs PM-solution >> (multilib-portage) and I propose not to convert ANYTHING else until >> that conflict is solved, even if it means a council vote (that's what >> I actually think makes sense here). >> I understand both sides and somehow find it appealing to have a >> quicker solution, but since this could damage years of work on a >> portage fork I think we should slow down here. > > except there _has_ been a discussion: > http://article.gmane.org/gmane.linux.gentoo.devel/80330 > > where, at least for me, it appeared that the eclass solution was the > right way and portage-multilib had its defects that could not be solved > without such an eclass solution. > Long story short: portage-multilib does not handle deps needing > multilib and deps not needing them. Only packages maintainers know > that, you cannot guess it at the PM level. Doing unpack twice, while > bearable, is also suboptimal. portage-multilib already disables its > multilib support for multilib-enabled packages, thus there is not even > a conflict there.
So you discussed with mgorny (who does not like multilib-portage) and not me and then assume that all details have been written in there? :-) > > The lack of answer on my reply > ( http://article.gmane.org/gmane.linux.gentoo.devel/82740 ) made me > think that the main portage-multilib developer was agreeing with that. Feel free to write my name here ;-) And it seems more likely i just missed that mail, i did not intentionally ignore it. Anyway, in short: the current implementation does add dependencies so that all dependencies need the same ABIs enabled as the package you want. If we move the features into a future EAPI, we can of course drop this and leave the dependency part to the ebuild maintainer. > > On the other hand, Michal has been doing the work and got things done > when portage-multilib has never reached mainline after several years > of development. So, while breaking the tree like the freetype case is > really bad, please do not use this for killing his efforts, esp. when > it is now masked. If you did not know it: anyone can add an eclass, while adding new features via package manager requires a new EAPI. I have written about it on this list for many months, if not years. And every time i solved a request, a new one was raised. And you want to blaim me for multilib-portage not reaching the main tree? Anyway, if there is a sane and easy to use eclass created, which does just multilib and does it properly for all multilib arches also supporting per ABI headers and binaries, i am not opposed against it. I just see issues the way a work-in-progress is pushed into the main tree without prior discussion and additional hacks for issues (freetype headers) forcing other devs to do more work instead of asking for another solution not needing any additional work for depending packages. -- Thomas Sachau Gentoo Linux Developer
signature.asc
Description: OpenPGP digital signature
