[Xcb] [ANNOUNCE] xcb-util 0.3.9

[Jeremy Huddleston]

On Jun 4, 2012, at 2:19 PM, Adam Jackson <ajax at redhat.com> wrote:

> On Mon, 2012-06-04 at 14:03 -0700, Jeremy Huddleston wrote:
>> On Jun 4, 2012, at 1:34 PM, Julien Cristau <jcristau at debian.org> wrote:
>>> How are the xcb_atom_get_predefined/xcb_atom_get_name_predefined
>>> removals not binary incompatible??
>> 
>> Nothing else changed, just the removal of the symbols.  All other
>> functions did not change their signatures.
> 
> That's irrelevant.

No, I think that's the key.  If I have an application that only used all those other symbols, and not these _predefined symbols, why should I need to relink my application?

If I was using these ..._predefined symbols, then I was not using public API, so I shot myself in the foot and can clean up my own mess.

>> Think about this from the libc perspective.  libc *may have* strlcat
>> or not, but they're named the same because all functions in libc have
>> consistent signatures.
> 
> A libc that had strlcat once, and then removed it, would no longer have
> the same ABI.  An application that had successfully linked against the
> old libc's strlcat would reasonably expect it to be present at runtime
> too.

That argument breaks down when you reverse it.  The "rules" state that the SONAME should not change when adding APIs.  If all you're basing this on is SONAME, then there is absolutely no difference between the adding and removing case.  If I link against a "newer" libc which has strlcat, then by your argument, I'd expect strlcat to be present on any libc matching that SONAME.  When I run my application with the older libc without strlcat, it will fail to find it.

SONAME is not the solution to this problem.  The best practice is to properly annotate "new" functions (so they are weak linked) and not remove public API until it is really warranted.

If you're removing a fringe API that is only used internally, then I'd argue against SONAME change.

> Removal of exported functions is an ABI break, even in Mach-O.  The
> soname (or dylib mahor version number) _should_ change.

That's silly.  If we did that, we should have bumped libX11's major number multiple times over the past few years, since what we really care about is public API, not exported symbols (yes, they should match, but in reality they don't).