On Thu, 07 Jun 2012 09:43:32 -0700
Zac Medico <firstname.lastname@example.org> wrote:
> 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@example.com> 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.
Whether we can convince Ciaran to change the wording of a feature in a
draft document is utterly irrelevant.
SLOT operator deps solve a large class of issues and wont get in the
way of solving the ranged dep problem in a later step, be it ABI_SLOT
or something more generic.
I'm all for getting SLOT operators into EAPI-5 as actually already
intended for earlier EAPIs. EAPI 5 was supposed to be a quick EAPI so
don't let us delay the whole thing because of that.
> > 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.
Again, it's not about getting someone to cooperate. Something that you
comment with "that might be nice" isn't ready for inclusion into EAPI 5.
> > 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.
What for? So we won't ever get rid of revdep-rebuild resp.
@preserved-libs? Except for the ranged dep problem I don't see any
additional benefit but potential drawbacks. Please correct me where I'm