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

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

[hasufell]

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


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.

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

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.

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

[Diego Elio Pettenò]

On 27/02/2013 18:10, hasufell wrote:
> 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

I'd say the only real mistake has been not keeping it masked to begin with.

Just so we're clear with everybody, I would suggest, the next time
somebody wants to introduce a disruptive change:

 1. commit it masked — this way even if it's going to mess up the whole
tree you won't be blamed;
 2. ask me for testing — this happened in this case, but (1) was missed;
 3. make sure you're around to keep the pieces.

I opened the bugs — I wasn't going to look into them any time soon,
mostly because I got another huge bunch of bugs already — I started
today, and after a while it became obvious (to hasufell) that many of
them came down to the same issue; now I know and I'm not opening bugs
for the same issue all over.

Another common one I found myself simply because I noticed it while
looking at the build log.

I don't see a big problem with 3. as Michał might not have reacted yet,
but it was not even 24 hours since he asked me to run the tinderbox. He
might have caught the cmake issue himself, I don't know.

So my final word is that yes, this was a screw up, no, not as big as it
transpire from here.

-- 
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

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 19:14:38 +0100
hasufell <hasufell@gentoo.org> 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?

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

I like to see multilib-portage as the temporary, available today,
solution and eclass based stuff as the long term and clean solution.

Alexis.

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@gentoo.org> 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

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 375 bytes --]

On Wed, 27 Feb 2013 20:05:58 +0100
hasufell <hasufell@gentoo.org> wrote:
> 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.

Eh, the only reason it's slow and painful for multilib is that no-one
seems to know what's actually been changed...

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Pacho Ramos]

[-- Attachment #1: Type: text/plain, Size: 1917 bytes --]

El mié, 27-02-2013 a las 18:10 +0100, hasufell escribió:
> 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
> 
> 
> 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.
> 
> 

Personally I don't think mgorny "broke a provider on purpose", he should
have released it hardmasked, but thinking he wanted to break testing on
purpose looks excessive to me. Also, most of that committed stuff was
tested for some time in x11 overlay, no? (not sure if probably freetype
was missed by some error, but clearly the transition to the eclasses
providing native multilib were tested "on purpose" in that overlay
before moving to the tree).

About PM-solution... I can't remember how many years we are waiting it
for being approved, and neither remember what was blocking it for
inclusion in eapi5 (as that threads usually end up being fairly long and
ending with blockers like PMS documentation changes and so :( )

I also remember this "conflict" between portage-multilib and eclasses
ways were discussed some weeks ago here (I thought specially between
mgorny and... aballier?)

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 489 bytes --]

On Wed, 27 Feb 2013 21:20:46 +0100
Pacho Ramos <pacho@gentoo.org> wrote:
> About PM-solution... I can't remember how many years we are waiting it
> for being approved, and neither remember what was blocking it for
> inclusion in eapi5 (as that threads usually end up being fairly long
> and ending with blockers like PMS documentation changes and so :( )

We're not waiting for it to be approved. We're waiting for someone to
tell us what the changes are.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Pacho Ramos]

[-- Attachment #1: Type: text/plain, Size: 605 bytes --]

El mié, 27-02-2013 a las 19:27 +0100, Alexis Ballier escribió:
[...]
> > 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 :)
> 

I also read that argument... but it looked to turn more in a "personal"
flame war than anything "technical". For example, I couldn't see how
multilib-portage solves the issue of different headers provided for
different arches (that looks to be the key problem that mgorny tried to
solve in freetype)


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Pacho Ramos]

[-- Attachment #1: Type: text/plain, Size: 3114 bytes --]

El mié, 27-02-2013 a las 18:58 +0100, Alexis Ballier escribió:
> 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.
> 
> 

Personally, I second this Alexis appreciations, I also highly appreciate
how Michal is working on getting things done and I doubt he broke the
tree on purpose (he has contacted me multiple times to ensure wouldn't
be collisions in transition period with emul packages, then, I doubt we
can blame on him saying he doesn't discuss things enough). He committed
a broken package? Yes, but also masked it soon enough and is working on
fixing the problem.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

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

[Thomas Sachau]

[-- Attachment #1: Type: text/plain, Size: 3163 bytes --]

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

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

Feel free to write my name here ;-)

And it seems more likely i just missed that mail, i did not
intentionally ignore it.

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.

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


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.

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.

-- 

Thomas Sachau
Gentoo Linux Developer


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 379 bytes --]

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

[Thomas Sachau]

[-- Attachment #1: Type: text/plain, Size: 916 bytes --]

Pacho Ramos schrieb:
> El mié, 27-02-2013 a las 19:27 +0100, Alexis Ballier escribió:
> [...]
>>> 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 :)
>>
> 
> I also read that argument... but it looked to turn more in a "personal"
> flame war than anything "technical". For example, I couldn't see how
> multilib-portage solves the issue of different headers provided for
> different arches (that looks to be the key problem that mgorny tried to
> solve in freetype)
> 

multilib-portage has no issues with abi-specific headers, since those
are installed into a seperate abi-specific location inside /usr/include
with a wrapper in the original location to not break depending packages.

-- 

Thomas Sachau
Gentoo Linux Developer


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 379 bytes --]

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 3032 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

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@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? :-)

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.

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:12:25 +0100
Thomas Sachau <tommy@gentoo.org> wrote:

> Pacho Ramos schrieb:
> > El mié, 27-02-2013 a las 19:27 +0100, Alexis Ballier escribió:
> > [...]
> >>> 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 :)
> >>
> > 
> > I also read that argument... but it looked to turn more in a
> > "personal" flame war than anything "technical". For example, I
> > couldn't see how multilib-portage solves the issue of different
> > headers provided for different arches (that looks to be the key
> > problem that mgorny tried to solve in freetype)
> > 
> 
> multilib-portage has no issues with abi-specific headers, since those
> are installed into a seperate abi-specific location
> inside /usr/include with a wrapper in the original location to not
> break depending packages.

yes, thats the kind of solution that should be implemented for
freetype too. putting all headers under /usr/lib doesnt seem sane.
There exist default locations for headers for a reason, leveraging the
issue to using pkg-config seems wrong.

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 20:05:58 +0100
hasufell <hasufell@gentoo.org> wrote:

> 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

- suboptimal (run all the src_* phases twice)
- from what i've understood it does not deal with nolib packages
  properly: what happens for eg coreutils or texlive-latexextra ? Do we
  unpack, build and install them twice ? Really ? Try to install
  tl-latexextra on a 5400rpm laptop disk, you'll see you do not want
  that time to double :)
- the spec will likely include specificities: e.g.
  setting PKG_CONFIG_PATH
  what happens if I want a multilib ocaml install (stupid idea btw but
  that's an example): the pkgconfig equivalent for ocaml is findlib.
  You will likely want to override OCAMLFIND_CONF for doing a multilib
  install. You will need to change the spec.

> 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

if done correctly this should not happen, but that's true the eapi
barrier is not there.

>   - needs much more modification on ebuilds, especially for weird
> build systems

the eclass you proposed implements more or less the multilib-portage
solution without much changes. if you want to do it cleanly (out of
source build, etc) then yes you need much more changes but also get
something you cannot do from the PM side.

>   - not tree-wide, slow per-package migration

it is a pro rather than a con for me: do we really want lib32 to be the
32bits copy of lib64? or do we want here only what actually makes
sense, on a per-package and per-need basis? (see also the tl-latexextra
example above)

Alexis.

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

[hasufell]

On 03/02/2013 12:08 PM, Alexis Ballier wrote:
> 
>> 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
> 
> if done correctly this should not happen, but that's true the eapi
> barrier is not there.
> 
>>   - needs much more modification on ebuilds, especially for weird
>> build systems
> 
> the eclass you proposed implements more or less the multilib-portage
> solution without much changes. if you want to do it cleanly (out of
> source build, etc) then yes you need much more changes but also get
> something you cannot do from the PM side.
> 
>>   - not tree-wide, slow per-package migration
> 
> it is a pro rather than a con for me: do we really want lib32 to be the
> 32bits copy of lib64? or do we want here only what actually makes
> sense, on a per-package and per-need basis? (see also the tl-latexextra
> example above)
> 

IMO we should go on with eclass development. Tommy has already offered
to help with that, but would appreciate if we implement a check/switch
that will disable all multilib-eclass related magic and allowing
multilib-portage to still work tree-wide as it did before we invented
these eclasses.

I think that's a fair trade.

And at least for my eclass I already have implemented a solution,
basically doing:

	if [[ $(multilib_get_enabled_abis) == ${DEFAULT_ABI} ]] ; then
		DISABLE_MULTILIB="ON"
	fi

which will disable multilib-behavior if only the default abi is set.
Alternatively we could simply introduce DISABLE_MULTILIB as an eclass
variable which can be set by multilib-portage then.

Mgorny still has not replied to this proposition.