Re: [gentoo-dev] About forcing rebuilds of other packages issue

[Ralph Sennhauser]

On Thu, 07 Jun 2012 09:43:32 -0700
Zac Medico <zmedico@g.o> 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 <pacho@g.o> 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
wrong.

Cheers.