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

[Alexis Ballier <aballier@gentoo.org>]

On Wed, 27 Feb 2013 18:10:30 +0100
hasufell <hasufell@gentoo.org> wrote:

> I don't want to start another useless rant here, because I perfectly
> understand the issue with ABI specific headers.
> 
> The problem is:
> a) if you break a provider on purpose, then you should feel
>  somehow responsible for the consumers and not just dump testing and
> fixing on your fellow devs
> b) just test such things in an overlay first and see it explode, then
> think about it again and ask on dev-ML if other people find it even
> WORTH the hassle

agreed with that

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

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.

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 want to start another discussion on the subject, then please
make a summary of the previous ones and start it (council will very
likely ask you to do it if you want a vote anyway). If you do not want
to, then please thank Michal for getting things done and finally giving
us a sane multilib support.

Alexis.