On Wednesday 2014-01-08 21:17, Lukas Slebodnik wrote:
The SONAME *can be* changed by setting "-version-info", but version-info is
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.
http://www.gnu.org/software/libtool/manual/html_node/Updating-version-inf...
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".
Because it would mean that public function was removed or API of some
function
was changed (backward incompatible change). And It is not true in case of
libref_array.
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?
>>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.
Yes,
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.