[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/freetype: freetype-2.4.11-r1.e
From:       Michał Górny <mgorny () gentoo ! org>
Date:       2013-02-27 21:18:26
Message-ID: 20130227221826.3b53ec30 () pomiocik ! lan
[Download RAW message or body]


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

> Alexis Ballier schrieb:
> > On Wed, 27 Feb 2013 18:10:30 +0100
> > hasufell <hasufell@gentoo.org> 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" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]