On Thu, 2014-01-09 at 12:47 +0100, Jan Engelhardt wrote:
On Wednesday 2014-01-08 21:17, Lukas Slebodnik wrote:
>The SONAME *can be* changed by setting "-version-info", but version-info
>libtool abstraction over different dynamic library version in the all
>supported platforms (Solaris, AIX, UX, BSD, Linux ...). Version-info should not
>be changed ad-hoc. There is algorithm how to change its value.
I am very well aware of all that. I have even seen many developers
abusing -version-info, but I can also tell you that -version-info N:0:0
(with two zeroes) is _within_ the "acceptable use".
>Your proposal with changing SONAME would solve problem, but it is not right.
It's not right, but it's _good enough_ (and arguably better than that
ill-fated pkg-config tuning attempt). The Right Thing™ would be to
write that symbol map, like fellow Redhatians Poettering and Sievers
have demonstrated in "libabc".
Sorry, but in my book changing the SONAME for a backwards compatible
change is not ok, as it requires rebuild all other packages that depends
on libref_array but do not use the new function unnecessarily (and no,
you cannot count on the fact you can install parallel versions, that is
allowed in debian, but not on Fedora for example).
>Because it would mean that public function was removed or API of
>was changed (backward incompatible change). And It is not true in case of
That conclusion is a red herring.
While the removal of public functions necessitates bumping SONAME,
a bumped SONAME is not indicative of removed functions, especially
if you consider that libtool on OpenBSD always just transplants
CURRENT to SONAME without bothering about REVISION and AGE.
But who cares, anyway?
I do, maintaining a stable SONAME is important, to avoid unnecessary
dependency breaks, and to be honest, if it weren't for platforms that do
not have symbol versioning, I would personally never change the soname
and use only symbol versioning.
>>>In my opinion, good enough solution would be to
explicitly require newer
>>>version of libref_array in the ini pkg-config file. It should be sufficient
>>>information for package maintainers.
>>That is _not_ sufficient. pkg-config would only specify dependencies
>>for the devel packages, not for the regular libraries.
>it is not perferct solution but only good enough. Because package maintainer
>need to check changes in the pkg-config file and manually adds requirement to
>the package description file (spec file in case of RPM based distribution)
And as you can see, that is the worst solution of all.
The only solution for backwards compatible changes that require a new
symbol with the same soname is to have an explicit version dependency in
the package management system. That can be enforced only at build time.
Simo Sorce * Red Hat, Inc * New York