On Tue, Apr 16, 2013 at 01:35:40PM -0700, Matt Turner wrote:
> I feel like this is getting out of control.

I'm just proposing an alternative approach.  Feel free to ignore ;).
Also, feel free to tell me to drop this issue for $x weeks until folks
have some more free time ;).

> There seems to be this overwhelming desire to keep applying hack after
> hack to make increasingly obscure -- and fundamentally unsupportable
> -- configurations work.

I was trying to replace the existing hack (from e7ea409, and 6c0a577
through f6ad38) with a simpler, less obscure one.

> Brian mentioned that he talked to Zac and that there was something
> that portage should be doing differently about binary packages. Let's
> please investigate that a bit further before pursuing other
> strategies. I have confidence that if Zac understands and knows about
> the problem that he can fix portage.

That sounds wonderful.  My impression was that neither Portage nor the
toolchain ebuilds were going to be changed to address this problem.
The last I hear on the Portage front was (quoted in [1]):

  10:33 < zmedico> dol-sen: wouldn't it be easier to just migrate
          those pkgs to EAPI 5 + slot-operator?
  10:34 * zmedico doesn't feel like doing extra work when EAPI 5
          already does everything we need
  …
  11:16 < Tommy[D]_> Zero_Chaos: my suggestion: ask the toolchain guys
          about their preferred way (like updating existing eclass,
          using a new eclass, moving code into ebuilds) and when you
          got that, do the needed work, including an EAPI-5 version of
          toolchain ebuilds

If Zac's changed his mind, I'd be happy to wait for the Portage bump
that works around poorly specified ABI dependencies.  However, note
that even some EAPI-5 packages don't use ABI sub-slots to avoid this
issue [2], so unless the Portage work-around deals with such ebuilds
appropriately, we'll still need some sort of hack in catalyst.

Cheers,
Trevor

[1]: http://mid.gmane.org/20130412162540.GB13054@odin.tremily.us
[2]: https://bugs.gentoo.org/show_bug.cgi?id=454184#c18
     (I'll work up the patches Zero_Chaos asks for in #c19 now, but I
     expect this is not an isolated event)

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy