On Fri, 2008-11-28 at 02:46 +0100, Yang Tse wrote:
> The introduction of a new public function somehow breaks API and ABI.
> 'People' are fond of saying that there is no need to make a SO bump
> when this is done. But actually it should be done. A program which
> counts on the existence of the new function will fail when faced with
> a shared library with the same SO number but which actually is a
> previous binary version in which the new function didn't exist yet. I
> won't argue this further, I just wanted to mention my personal opinion
> on what I think is a wrong-doing but quite common practice.
It's certainly true that you could make it your policy to bump the
SONAME whenever there is any externally visible change to the library.
But, if you go down this road, you would end up changing SONAME on
virtually any release. For example, even if there was already an
ares_setopt() function, programs which relied on the availability of a
particular ARES_OPT_something option might fail if run against an older
library which didn't understand that bit. Taken to the extreme, you
could argue that even internal bugfixes would justify a SONAME bump,
since programs relying on the newly-corrected behaviour might do the
wrong thing if they were accidentally run against an old, unfixed
version of the library.
But, the purpose of the SONAME has never been to provide full dependency
tracking for distributed binaries: that problem is solved just fine by
RPM, dpkg and the like. The main role of the SONAME is to allow you to
install multiple versions of the same library in parallel when this is
necessary for correct operation of some or other binaries, and to allow
each binary to select the appropriate version of the library. And, the
only time it makes any sense to start installing multiple versions in
parallel is when older binaries can no longer run correctly with newer
library versions. If you force people to recompile all their binaries
in order to link against each newer version of c-ares then you would
lose a large part of the benefit of having a shared library in the first
place.
p.
Received on 2008-11-28