-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 01/09/2014 08:42 AM, Simo Sorce wrote:
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 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-info.h...
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 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?
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.
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.
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.
It's also worth noting that the way we treat the build in Fedora and RHEL is to require that all sub-packages produced from the source tarball have explicit version requirements on the same version. This is done to avoid the exact sort of issues you saw. We only ever test their compatibility with the version provided in the exact same build.
The wisest move to make would be to just guarantee that the ref_array and ini_config packages must always upgrade together with an explicit dependency.