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

[simo]

On Thu, 2009-07-02 at 13:52 +1000, tridge at samba.org wrote:
> 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. 

Tridge, it's not that simple.

Sure, soname bumps can be made, but that does not mean you have no
problems. They are done lightly only when the libraries are "internal"
to a project so that you know all components installed at any single
time will have no issues, or when you can guarantee you will upgrade all
libraries. (Ie you never have both libraries installed).

You can't have the 2 libraries installed at the same time.
If, through dependencies, both get loaded in the same process space, and
both use the same symbol names, you are doomed.

Now think of installing a newer samba version (including pam_winbindd
and libsmbclient) into an older system. 

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

Only upstream know when changes are compatible or not, it's obviously
the upstream duty.

> Looking at the lib/talloc directory, do I just edit the AC_INIT()
> line:
> 
>   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?

Can I ask you a question in reverse ?
Why is it so imperative for you to break the ABI ?
Why can't we fix the bug without breaking it ?
I didn't see anything in this bug that couldn't be fixed and yet
maintain the original ABI intact.

>  > 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?

No, they will have to be rebuilt at the very least.

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

No you can't keep talloc.so.1 and talloc.so.2 at the same time in the
distro, it is too dangerous. Distros will have to wait till next distro
version or rebuild all applications that depend on talloc.

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

There is indeed, and it would be preferable to go talloc2 if there are
changes so large the API and ABI compatibility cannot be maintained.
Given the API is compatible it should be extremely easy to maintain the
ABI as compatible as well, so why not ?

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

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

It's unnecessary changes that are frown upon. We don't have the greatest
and brightest new talloc here it's not like going from kde3 to kde4
where you rename the .so of all libs from 3 to 4, this is just a minor
bug fix for a feature that is not much used.
So why should we piss off others and make it difficult for them when we
can fix it without causing pain ?
What is so special about us that we can't show a bit of respect towards
people that entrusted us to provide a library for others to use ?

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer <simo at samba.org>
Principal Software Engineer at Red Hat, Inc. <simo at redhat.com>