On Thu, 07 Jun 2012 09:43:32 -0700 Zac Medico <zmed...@gentoo.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 <pa...@gentoo.org> 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.
signature.asc
Description: PGP signature
