On 06/06/2012 02:10 AM, Pacho Ramos wrote:
> El mié, 06-06-2012 a las 01:54 -0700, Zac Medico escribió:
> On 06/06/2012 01:46 AM, Pacho Ramos wrote:
>>>> El mar, 05-06-2012 a las 19:18 -0700, Zac Medico escribió:
>>>>> On 06/05/2012 05:51 PM, Michael Weber wrote:
>>>>>> Is there any chance to detect this ZLIB_VERSION problem with
>>>>>> revdep-rebuild (worst case: add a list of possibly broken
>>>>>> packages with tests)?
>>>>> I'd suggest a special ebuild phase to check for ABI changes, like
>>>>> the pre_pkg_preinst_abi_check phase suggested here:
>>>> I guess, that phase would detect ABI change and package manager
>>>> would know how to handle it by itself?
> Yeah, it would be like a warning system, do detect cases when the
> SLOT/ABI_SLOT were not bumped when they should have been. The idea is
> that the developer who's doing the version bump will see the warning
> and bump the SLOT/ABI_SLOT before committing the ebuild.
> And once we bump SLOT/ABI_SLOT, package manager would know about how to
> handle that situation and rebuild needed stuff?
Right, as long as the reverse dependencies use the := "SLOT operator"
like they're supposed to. That's how they let the package manager know
that they'll need to be rebuilt when the ABI changes.
> If we use SLOT only, I guess we would need to allow (or make more
> common) pulling multiple slot but all of them mutually exclusive no?
Yeah, blockers are already used like this sometimes, like for
google-chrome which has mutually exclusive stable, beta, and unstable SLOTs.
> have no problem with that of course, but I thought it wasn't "desired"
> in general.
Well, we can always introduce a separate ABI_SLOT variable in a later
EAPI, if we want.