1 |
On 06/06/2012 02:59 PM, Brian Harring wrote: |
2 |
> On Tue, Jun 05, 2012 at 07:18:01PM -0700, Zac Medico wrote: |
3 |
>> On 06/05/2012 05:51 PM, Michael Weber wrote: |
4 |
>>> Is there any chance to detect this ZLIB_VERSION problem with |
5 |
>>> revdep-rebuild (worst case: add a list of possibly broken packages |
6 |
>>> with tests)? |
7 |
>> |
8 |
>> I'd suggest a special ebuild phase to check for ABI changes, like the |
9 |
>> pre_pkg_preinst_abi_check phase suggested here: |
10 |
>> |
11 |
>> https://bugs.gentoo.org/show_bug.cgi?id=192319#c20 |
12 |
> |
13 |
> Same thing I said in '07; I don't have a problem w/ hooks for ebuilds |
14 |
> to specify additional QA checks, but this *cannot* be the user's end |
15 |
> solution- it needs to be purely for making it easier for devs to spot |
16 |
> their screwups. In other words, revdep-rebuild shouldn't be involved; |
17 |
> this should spot/complain that zlib (for example) changed abi w/out a |
18 |
> matching metadata setting/whatever, rather than having checks done in |
19 |
> the consumers. |
20 |
> |
21 |
> Using this for anything other than a QA check of the originating |
22 |
> package, basically has an end result of us going towards a |
23 |
> non-deterministic resolution model- which is a clusterfuck, frankly. |
24 |
|
25 |
Yeah, I'm sure we can all agree that we would like the dependency |
26 |
resolver to be able to predict/display all of the rebuilds that will |
27 |
need to occur, before any building starts. |
28 |
-- |
29 |
Thanks, |
30 |
Zac |