[SSSD] ding-libs: symbol versioning is necessary

Jakub Hrozek jhrozek at redhat.com
Thu Jan 9 16:19:23 UTC 2014


On Thu, Jan 09, 2014 at 11:09:09AM -0500, Stephen Gallagher wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 01/09/2014 09:39 AM, Jan Engelhardt wrote:
> > 
> > On Thursday 2014-01-09 14:42, Simo Sorce wrote:
> >> 
> >> Sorry, but in my book changing the SONAME for a backwards
> >> compatible change is not ok [...] I do, maintaining a stable
> >> SONAME is important [...] 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.
> > 
> > Hey, keeping SONAME and doing symbol version maps was my
> > preferential pick as well, but Lukas Slebodnik did not want to.
> > Come on, is it really _so much_ work to maintain a symbol version
> > file? How many symbols get added anyway?
> > 
> 
> The conversation got sidetracked by the soname bumping discussion
> (which is a terrible idea and should be dropped immediately). Imagine
> if glibc bumped soname every time it added a function...
> 
> I agree that maintaining the table shouldn't be a huge added effort,
> but one that we do need to codify into our release process
> documentation so we don't ever miss it.
> 
> > Just give me a clear answer already. Will sssd address the issue, 
> > or is it going to be a "fuck you" to downstream packagers?
> 
> That kind of language is unnecessary and offensive. Please tone it down.
> 
> We have been discussing the merits of symbol versioning today in the
> IRC channel. Given the advantages inherent in being able to
> auto-detect these versioned dependencies in both the RPM and DEB
> build-systems, adding this version map seems to be the best approach.

Thanks for having the discussion on IRC! Would you (or Lukas, or Simo)
like to file a ticket for both SSSD and ding-libs ?



More information about the sssd-devel mailing list