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 07:27 PM, Alexis Ballier wrote:
> On Wed, 27 Feb 2013 19:14:38 +0100
> hasufell <hasufell@g.o> wrote:
>
>> 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.
>
> What are the problems exactly? I'm likely misinformed, but to me it
> seemed there is nothing EAPI-related there. What kind of spec (read:
> pms diff) do we need?

E.g. that you cannot enabled/disable ABIs on a per-package basis.

Feb 26 22:04:07 <hasufell>	Tommy[D]: per-package setting is possible as
well?
Feb 26 22:05:19 <Tommy[D]>	hasufell: adding the features to EAPI-6, you
can do it per package too, yes

Feb 26 22:04:40 <mgorny>	Tommy[D]: when is it going to be available in
mainstream Gentoo?
Feb 26 22:07:45 <Tommy[D]>	mgorny: you want it? i could switch my free
time into it after being done with another recruitment

Feb 26 22:12:02 <hasufell>	what is the portage maintainers opinion on
this fork?
Feb 26 22:14:49 <Tommy[D]>	afaik zmedico has no issues with it, also i
dont know how close his look on the code itself has been


Afaiu this seems to be mainly a PMS thing. And changing PMS is slow and
painful, so no wonder people rather want to go for eclass based solutions.

>
>> 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.
>
> What are these arguments ? The IRC conspiracy is hard to follow :)
>
>>> 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.
>
> Again, without a summary of pros and cons and an old discussion that
> died leaving the eclass solution as a winner, it is a bit harsh to ask
> for a vote.
>

This is just my own view on this and NOT complete, Tommy[D] will
probably have a more complete list what the eclasses currently lack and
where they will fail.
Mgorny will have a more complete list why multilib-portage is a bad hack.


PM level:
pro:
  - one-blow solution, tree-wide
  - _much_ less modification on ebuilds needed
  - will be properly documented in the spec, something people can
    rely on
  - multilib-portage has years of experience on ABI issues
con:
  - difficult to maintain (please count the number of people who
    understand portage code)
  - slower fixes
  - still no merge into mainline in sight, could very well take another
    few months, if at all


eclass level:
pro:
  - easier to maintain (eclasses are generally easy understandable)
  - quicker to fix and to extend
  - solution is NOW available
con:
  - more likely to break stuff as all eclass based solutions, because
    there are no eclass-APIs and no spec
  - needs much more modification on ebuilds, especially for weird build
    systems
  - not tree-wide, slow per-package migration