On Wed, Jun 06, 2012 at 05:43:49PM -0700, Zac Medico wrote: > On 06/06/2012 12:23 PM, Ciaran McCreesh wrote: > > On Wed, 06 Jun 2012 21:16:05 +0200 > > Pacho Ramos <[email protected]> wrote: > >> Well, I think reading this thread is more or less clear what it would > >> be supposed to do, also Zac suggested it and looks to have an idea > >> about what should it do. > > > > There's a big leap from "more or less clear" and "an idea" to the kind > > of knowledge we want to have. Think REQUIRED_USE for how this can go > > wrong... > > > > If you think ABI_SLOT is essential, why not try implementing it and > > trying it out in a large number of packages, and reporting your results? > > It's pretty close to the SLOT operator model, and it seems like it > should work fine. We can deploy EAPI 5_pre1 with ABI_SLOT support, and > test it in an overlay before we include it in the final EAPI 5.
I'd prefer you nailing down the details a bit more before slipping it into an EAPI called "5_pre1"; aside from usual complaints, frankly I'd rather not have to figure out the design of it via raiding the patches out of portage history ;) If we're going to do this, there should be a way to represent the direction of compatibility. Might be overthinking it, but consider upgrades where new API is added; this does *not* break ABI, it extends it. Going in reverse however *would* break ABI for anything that was using the new additions. This issue can be avoided via usage of version operators w/ appropriate slot binding deps, just seems hanky in light of what we're talking about. I'm perfectly fine w/ ABI_SLOT and SLOT (I proposed a similar thing in '06/'07); I'd however suggest ensuring there is some buy in from devs on that one since that was the main argument against it in the past. That argument may no longer apply, but should be checked imo. ~harring
