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

[Alexis Ballier]

On Wed, 27 Feb 2013 22:08:45 +0100
Thomas Sachau <tommy@g.o> wrote:

> Alexis Ballier schrieb:
> > On Wed, 27 Feb 2013 18:10:30 +0100
> > hasufell <hasufell@g.o> 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? :-)

It is probably rather that mgorny's approach is much more transparent:
He sends his ideas to the ml, ask for comments, etc. while
the multilib-portage approach is not clear to anybody. "All details"
are, in fact, what I understood from the list of commands and
pseudo-algorithm you sent as a spec some time ago :)

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

How do you achieve that currently? We _do_ need to leave the dependency
part to the ebuild maintainer: How will you achieve that?
cat/pkg[$MULTIlIB_USE_DEP] ? :) I don't think we need a future EAPI for
this. If you spec it, do we need a new EAPI everytime we want to
introduce a new ABI?

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

I don't blame multilib-portage for not reaching mainline. From what
I've seen, the only needed change I've understood is changing how the
ebuild phases are called. The rest is obscure and not precise enough to
me, unfortunately.
You always claimed that multilib-portage works on the current tree, so
I do not see what eapi part you need, just change your pm to do
multilib and be done, no ?

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

Good.

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

He sent all is changes over the ml for review. Everybody was happy, he
committed them. Nothing wrong here. The freetype issue is different,
and IMHO the solution is wrong there. Let me check bgo and file a bug
if not.

Alexis.