1 |
On 06/07/2012 11:04 AM, Ralph Sennhauser wrote: |
2 |
> On Thu, 07 Jun 2012 09:43:32 -0700 |
3 |
> Zac Medico <zmedico@g.o> wrote: |
4 |
> |
5 |
>> On 06/07/2012 01:24 AM, Brian Harring wrote: |
6 |
>>> I'm perfectly fine w/ ABI_SLOT and SLOT (I proposed a similar thing |
7 |
>>> in '06/'07); I'd however suggest ensuring there is some buy in from |
8 |
>>> devs on that one since that was the main argument against it in the |
9 |
>>> past. |
10 |
>> |
11 |
>> I can imagine that ABI_SLOT operator deps will be a lot more popular |
12 |
>> than SLOT operator deps, since ABI_SLOT operator deps will accommodate |
13 |
>> the common practice of allowing ABI changes within a particular SLOT. |
14 |
> |
15 |
> What for? So we won't ever get rid of revdep-rebuild resp. |
16 |
> @preserved-libs? Except for the ranged dep problem I don't see any |
17 |
> additional benefit but potential drawbacks. Please correct me where I'm |
18 |
> wrong. |
19 |
|
20 |
ABI_SLOT operator deps *do* allow us to get rid of revdep-rebuild, since |
21 |
they are usable in cases like the dbus-glib/glib:2 dependency, where |
22 |
SLOT operator deps are unmanageable. |
23 |
-- |
24 |
Thanks, |
25 |
Zac |