On 06/07/2012 01:24 AM, Brian Harring wrote: > 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 ;)
Ciaran already has SLOT operators in his eapi-5 branch of PMS. Maybe we can convince him to change it to ABI_SLOT operators. > 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. That might be nice, but it also complicates things a bit. We might stand a better chance of getting Ciaran to cooperate if we keep it simpler and stay closer to the SLOT operator model. > 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. I can imagine that ABI_SLOT operator deps will be a lot more popular than SLOT operator deps, since ABI_SLOT operator deps will accommodate the common practice of allowing ABI changes within a particular SLOT. -- Thanks, Zac
