1 |
On 06/06/2012 02:10 AM, Pacho Ramos wrote: |
2 |
> El mié, 06-06-2012 a las 01:54 -0700, Zac Medico escribió: |
3 |
> On 06/06/2012 01:46 AM, Pacho Ramos wrote: |
4 |
>>>> El mar, 05-06-2012 a las 19:18 -0700, Zac Medico escribió: |
5 |
>>>>> On 06/05/2012 05:51 PM, Michael Weber wrote: |
6 |
>>>>>> Is there any chance to detect this ZLIB_VERSION problem with |
7 |
>>>>>> revdep-rebuild (worst case: add a list of possibly broken |
8 |
>>>>>> packages with tests)? |
9 |
>>>>> |
10 |
>>>>> I'd suggest a special ebuild phase to check for ABI changes, like |
11 |
>>>>> the pre_pkg_preinst_abi_check phase suggested here: |
12 |
>>>>> |
13 |
>>>>> https://bugs.gentoo.org/show_bug.cgi?id=192319#c20 |
14 |
>>>> |
15 |
>>>> I guess, that phase would detect ABI change and package manager |
16 |
>>>> would know how to handle it by itself? |
17 |
> |
18 |
> Yeah, it would be like a warning system, do detect cases when the |
19 |
> SLOT/ABI_SLOT were not bumped when they should have been. The idea is |
20 |
> that the developer who's doing the version bump will see the warning |
21 |
> and bump the SLOT/ABI_SLOT before committing the ebuild. |
22 |
>> |
23 |
>> |
24 |
> |
25 |
> And once we bump SLOT/ABI_SLOT, package manager would know about how to |
26 |
> handle that situation and rebuild needed stuff? |
27 |
|
28 |
Right, as long as the reverse dependencies use the := "SLOT operator" |
29 |
like they're supposed to. That's how they let the package manager know |
30 |
that they'll need to be rebuilt when the ABI changes. |
31 |
|
32 |
> If we use SLOT only, I guess we would need to allow (or make more |
33 |
> common) pulling multiple slot but all of them mutually exclusive no? |
34 |
|
35 |
Yeah, blockers are already used like this sometimes, like for |
36 |
google-chrome which has mutually exclusive stable, beta, and unstable SLOTs. |
37 |
|
38 |
> I |
39 |
> have no problem with that of course, but I thought it wasn't "desired" |
40 |
> in general. |
41 |
|
42 |
Well, we can always introduce a separate ABI_SLOT variable in a later |
43 |
EAPI, if we want. |
44 |
-- |
45 |
Thanks, |
46 |
Zac |