[SSSD] ding-libs: symbol versioning is necessary

Stephen Gallagher sgallagh at redhat.com
Thu Jan 9 14:34:26 UTC 2014


-----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.html
>>
>>
>>> 
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.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlLOs3IACgkQeiVVYja6o6PruACfZD1lOLYXOOibnLfR/G4NYXju
+nsAoJn8e9EdT+6TNSjLBT/uXFaupJwD
=c7ie
-----END PGP SIGNATURE-----



More information about the sssd-devel mailing list