[SSSD] ding-libs: symbol versioning is necessary

Simo Sorce simo at redhat.com
Thu Jan 9 13:42:17 UTC 2014


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.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York




More information about the sssd-devel mailing list