On 02/27/2013 06:58 PM, Alexis Ballier 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.

I don't even know multilib-portage (think is this way around) that
detailed myself, but Tommy[D] claims that some of those problems will be
solved in EAPI=6 and that he is willing to work on the spec.

The reason I bring this up again is that there was a strong argument
yesterday in #gentoo-dev, so it seems the situation is NOT clear.


> 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.
> 

It still does not make sense to work in two different directions, imo. I
was supporting the eclass idea myself by proposing
autotools-multilib-minimal.eclass, but I think this should be voted on,
so we don't duplicate work.

Reply via email to