[SCM] Samba Shared Repository - branch master updated - release-4-0-0alpha8-154-g826ee30

tridge at samba.org tridge at samba.org
Thu Jul 2 03:52:48 GMT 2009

Hi Jeremy,

 > For as long as we're shipping talloc.so.1.x. That's the promise
 > we made when we released talloc as an external library.

so if we increase the version number to talloc.so.2.x now, then we
don't need the workarounds. 

 > Yes - that's the point. You got rid of them without
 > bumping talloc to talloc.so.2.

err, I don't know how to bump the soname version. I had assumed that
was the responsibility of the external shared library maintainer,
which isn't me. 

Looking at the lib/talloc directory, do I just edit the AC_INIT()

  AC_INIT(talloc, 1.3.1)

or is there something else I need to do? Is this my job as upstream
maintainer of talloc?

 > Now you might want to do this for this bugfix but it really doesn't
 > warrent that sort of a change (IMHO) and will lead to multiple
 > versions of the talloc ABI that I really don't think we should do.

why don't we want a new version? It has new functionality, it has bug
fixes, and it has a different ABI. Why doesn't that justify changing
the soname version? What is the criterion for changing the number if
not that?

 > But we've released this library. We've gotten people using it
 > in other applications. This isn't only our code anymore.

and if we change the soname number then all those existing apps will
keep working - no?

Of course 'working' is relative, they will have the bugs that we've
just fixed. I'll be quite surprised if openchange and other talloc
users don't want to move to the new code.

 > We *have* to maintain backwards compatibility with small
 > bugfixes like this in order to maintain *any* credibility
 > as a provider of system libraries. It isn't like Metze's
 > fix is hard to do or would damage the code in any way. It
 > just shows a commitment to ABI stability.

we have maintained source code compatibility. The idea of never
bumping the soname seems silly to me.

 > If this were a larger change, which warrented talloc2,
 > then I'd agree.

talloc2 would be a totally new package. talloc.so.2 is a soname
change. There is a world of difference between the two.

 > But to arbitrarily change the ABI like this when we don't have to
 > is gratuatous change, that gives Free Software production a bad
 > name.

ok, this is just getting silly. Have a look in /usr/lib on your
system. Look at how many libs are at version 5 or 6 or later. Then
notice the complete lack of articles that have been written on the
horrible consequences for the FOSS community of all those libraries
using .so numbers for exactly what they are intended for.

I have never noticed any teeth gnashing over the doom of free software
because some library changed its version number, except in this email

Cheers, Tridge

More information about the samba-technical mailing list