Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/freetype: freetype-2.4.11-r1.ebuild ChangeLog

[hasufell]

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.