Hi, On Mon, 2015-09-07 at 12:16 +0200, Andreas Henriksson wrote: > Yes, everything built after/against the new libical will pick up > the new ABI and work (only) with the new version. > In debian we try to support partial upgrades though (eg. mixtures > of stable and testing), so this is still considered a bug even if we > rebuild all reverse dependencies of libical.
I see. > Yes upstream seems to think so, that's what fooled me into believing > the update was safe. It doesn't seem to be true though. > Every time new header files are generated there's a risk of ABI > breakage since something new might have been added to the source > database which will get *sorted* during header/enum generation which > means the new addition might get added to the middle (rather then the > end, which would have been perferctly fine,) of the enum breaking ABI > for everything in the enum after the new addition. > > This was actually caught when the sorting patch was first introduced > .... see: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=773916#27 Isn't the explicit assignment of (stable) numeric values to the symbolic constants done in [0] also supposed to prevent exactly that? The generated enums might have new entries in the middle, but the *numeric* values of the old entries should still be the same. IIRC the ordering in enums only matters if the corresponding numerical values are not (all) set explicitly, but automatically set by the compiler. > Since we support partial upgrades, the broken ABI is still a bug > and needs a transition. Agreed, but from what I can tell, a SONAME bump (along with the corresponding transition) is all that's required, there should be no changes necessary to the actual code. Best regards Alexander Kurtz [0] https://github.com/libical/libical/tree/master/design-data
signature.asc
Description: This is a digitally signed message part
