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

[Zac Medico]

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.

> 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