-----BEGIN PGP SIGNED MESSAGE-----
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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
-----END PGP SIGNATURE-----