1 |
On 06/07/2012 01:24 AM, Brian Harring wrote: |
2 |
> On Wed, Jun 06, 2012 at 05:43:49PM -0700, Zac Medico wrote: |
3 |
>> On 06/06/2012 12:23 PM, Ciaran McCreesh wrote: |
4 |
>>> On Wed, 06 Jun 2012 21:16:05 +0200 |
5 |
>>> Pacho Ramos <pacho@g.o> wrote: |
6 |
>>>> Well, I think reading this thread is more or less clear what it would |
7 |
>>>> be supposed to do, also Zac suggested it and looks to have an idea |
8 |
>>>> about what should it do. |
9 |
>>> |
10 |
>>> There's a big leap from "more or less clear" and "an idea" to the kind |
11 |
>>> of knowledge we want to have. Think REQUIRED_USE for how this can go |
12 |
>>> wrong... |
13 |
>>> |
14 |
>>> If you think ABI_SLOT is essential, why not try implementing it and |
15 |
>>> trying it out in a large number of packages, and reporting your results? |
16 |
>> |
17 |
>> It's pretty close to the SLOT operator model, and it seems like it |
18 |
>> should work fine. We can deploy EAPI 5_pre1 with ABI_SLOT support, and |
19 |
>> test it in an overlay before we include it in the final EAPI 5. |
20 |
> |
21 |
> I'd prefer you nailing down the details a bit more before slipping it |
22 |
> into an EAPI called "5_pre1"; aside from usual complaints, frankly I'd |
23 |
> rather not have to figure out the design of it via raiding the patches |
24 |
> out of portage history ;) |
25 |
|
26 |
Ciaran already has SLOT operators in his eapi-5 branch of PMS. Maybe we |
27 |
can convince him to change it to ABI_SLOT operators. |
28 |
|
29 |
> If we're going to do this, there should be a way to represent |
30 |
> the direction of compatibility. Might be overthinking it, but |
31 |
> consider upgrades where new API is added; this does *not* break ABI, |
32 |
> it extends it. Going in reverse however *would* break ABI for |
33 |
> anything that was using the new additions. This issue can be avoided |
34 |
> via usage of version operators w/ appropriate slot binding deps, just |
35 |
> seems hanky in light of what we're talking about. |
36 |
|
37 |
That might be nice, but it also complicates things a bit. We might stand |
38 |
a better chance of getting Ciaran to cooperate if we keep it simpler and |
39 |
stay closer to the SLOT operator model. |
40 |
|
41 |
> I'm perfectly fine w/ ABI_SLOT and SLOT (I proposed a similar thing in |
42 |
> '06/'07); I'd however suggest ensuring there is some buy in from devs |
43 |
> on that one since that was the main argument against it in the past. |
44 |
|
45 |
I can imagine that ABI_SLOT operator deps will be a lot more popular |
46 |
than SLOT operator deps, since ABI_SLOT operator deps will accommodate |
47 |
the common practice of allowing ABI changes within a particular SLOT. |
48 |
-- |
49 |
Thanks, |
50 |
Zac |