| 1 |
On Thu, 21 Jun 2012 08:13:50 -0500 |
| 2 |
Homer Parker <hparker@g.o> wrote: |
| 3 |
> > And what did Gentoo get out of it? |
| 4 |
> > |
| 5 |
> > What I remember is Gentoo putting in lots of work randomly changing |
| 6 |
> > things until things worked, and ending up not knowing what most of |
| 7 |
> > those changes were or why they were done. The end result is that |
| 8 |
> > there's still a random smattering of multilib-related mess |
| 9 |
> > cluttering up ebuild internals that doesn't actually do anything |
| 10 |
> > except cause intermittent breakages. Doing experiments is great as |
| 11 |
> > a way of understanding the problem, but it isn't how you deliver a |
| 12 |
> > solution. That takes a lot more work, and someone has to be |
| 13 |
> > prepared to do it. |
| 14 |
> |
| 15 |
> The hell? Other distos where still thinking of how to |
| 16 |
> implement multilib and we had it. I know first hand as I trashed a |
| 17 |
> system trying out the latest-n-greatest.. And the next round fixed |
| 18 |
> it. The -emul packages from then on along with the multilib profiles |
| 19 |
> have worked fine. |
| 20 |
|
| 21 |
...so why are people running around demanding that reinventing multilib |
| 22 |
is the number one priority and has to be in EAPI 5 immediately then? I |
| 23 |
was under the impression that your fellow developers don't consider the |
| 24 |
-emul packages to be an adequate solution. If that isn't the case, and |
| 25 |
the existing mechanism is in fact fine as you claim, then great, we can |
| 26 |
ignore multilib from an EAPI perspective. |
| 27 |
|
| 28 |
I can only go on what your colleagues are claiming here. I suggest if |
| 29 |
you're upset at the suggestion that Gentoo doesn't have a decent |
| 30 |
multilib implementation then you take it up with all the people who are |
| 31 |
demanding the PMS team provide them with one. |
| 32 |
|
| 33 |
-- |
| 34 |
Ciaran McCreesh |
Archives