Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-dev
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: Brian Harring <ferringb@...>
From: Zac Medico <zmedico@g.o>
Subject: Re: About forcing rebuilds of other packages issue
Date: Thu, 07 Jun 2012 09:43:32 -0700
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


Replies:
Re: About forcing rebuilds of other packages issue
-- Ralph Sennhauser
Re: About forcing rebuilds of other packages issue
-- Ciaran McCreesh
References:
Re: About forcing rebuilds of other packages issue
-- Zac Medico
Re: About forcing rebuilds of other packages issue
-- Ciaran McCreesh
Re: About forcing rebuilds of other packages issue
-- Pacho Ramos
Re: About forcing rebuilds of other packages issue
-- Ciaran McCreesh
Re: About forcing rebuilds of other packages issue
-- Pacho Ramos
Re: About forcing rebuilds of other packages issue
-- Ciaran McCreesh
Re: About forcing rebuilds of other packages issue
-- Pacho Ramos
Re: About forcing rebuilds of other packages issue
-- Ciaran McCreesh
Re: About forcing rebuilds of other packages issue
-- Zac Medico
Re: About forcing rebuilds of other packages issue
-- Brian Harring
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: About forcing rebuilds of other packages issue
Next by thread:
Re: About forcing rebuilds of other packages issue
Previous by date:
Re: x32 release candidate
Next by date:
Re: About forcing rebuilds of other packages issue


Updated Jun 29, 2012

Summary: Archive of the gentoo-dev mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.