On Wed, 27 Feb 2013 22:08:45 +0100 Thomas Sachau <[email protected]> wrote:
> 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? :-) You're making this more and more confusing. I don't know if you're doing that intentionally or by accident but please try to make it clearer what multilib-portage can and cannot do rather than keeping it all blurry. > > 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? You told me yesterday that so far you haven't even listed all the details on how multilib-portage works on the ml. Do you expect us to accept the feature without even having it explained first? > 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. Believe it or not, this is a proper solution. Hacking it around does not fix the actual issues. -- Best regards, Michał Górny
signature.asc
Description: PGP signature
