| 1 |
On Wed, 27 Feb 2013 19:14:38 +0100 |
| 2 |
hasufell <hasufell@g.o> wrote: |
| 3 |
|
| 4 |
> On 02/27/2013 06:58 PM, Alexis Ballier wrote: |
| 5 |
> > |
| 6 |
> >> The other thing is: |
| 7 |
> >> We still have the conflict with eclass-solution vs PM-solution |
| 8 |
> >> (multilib-portage) and I propose not to convert ANYTHING else until |
| 9 |
> >> that conflict is solved, even if it means a council vote (that's |
| 10 |
> >> what I actually think makes sense here). |
| 11 |
> >> I understand both sides and somehow find it appealing to have a |
| 12 |
> >> quicker solution, but since this could damage years of work on a |
| 13 |
> >> portage fork I think we should slow down here. |
| 14 |
> > |
| 15 |
> > except there _has_ been a discussion: |
| 16 |
> > http://article.gmane.org/gmane.linux.gentoo.devel/80330 |
| 17 |
> > |
| 18 |
> > where, at least for me, it appeared that the eclass solution was the |
| 19 |
> > right way and portage-multilib had its defects that could not be |
| 20 |
> > solved without such an eclass solution. |
| 21 |
> |
| 22 |
> I don't even know multilib-portage (think is this way around) that |
| 23 |
> detailed myself, but Tommy[D] claims that some of those problems will |
| 24 |
> be solved in EAPI=6 and that he is willing to work on the spec. |
| 25 |
|
| 26 |
What are the problems exactly? I'm likely misinformed, but to me it |
| 27 |
seemed there is nothing EAPI-related there. What kind of spec (read: |
| 28 |
pms diff) do we need? |
| 29 |
|
| 30 |
> The reason I bring this up again is that there was a strong argument |
| 31 |
> yesterday in #gentoo-dev, so it seems the situation is NOT clear. |
| 32 |
|
| 33 |
What are these arguments ? The IRC conspiracy is hard to follow :) |
| 34 |
|
| 35 |
> > Long story short: portage-multilib does not handle deps needing |
| 36 |
> > multilib and deps not needing them. Only packages maintainers know |
| 37 |
> > that, you cannot guess it at the PM level. Doing unpack twice, while |
| 38 |
> > bearable, is also suboptimal. portage-multilib already disables its |
| 39 |
> > multilib support for multilib-enabled packages, thus there is not |
| 40 |
> > even a conflict there. |
| 41 |
> > |
| 42 |
> |
| 43 |
> It still does not make sense to work in two different directions, |
| 44 |
> imo. I was supporting the eclass idea myself by proposing |
| 45 |
> autotools-multilib-minimal.eclass, but I think this should be voted |
| 46 |
> on, so we don't duplicate work. |
| 47 |
|
| 48 |
Again, without a summary of pros and cons and an old discussion that |
| 49 |
died leaving the eclass solution as a winner, it is a bit harsh to ask |
| 50 |
for a vote. |
| 51 |
|
| 52 |
I like to see multilib-portage as the temporary, available today, |
| 53 |
solution and eclass based stuff as the long term and clean solution. |
| 54 |
|
| 55 |
Alexis. |
Archives