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

Andrew Bartlett abartlet at samba.org
Thu Jul 2 05:03:32 GMT 2009


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. 
> 
>  > 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()
> 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?

Yes.  (At least, as this is the formal package version, I'm not sure if
the .so also comes from somewhere else)

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

I really think, given the young life of talloc and the need to fix this
once and for all, that we find the talloc-using projects (can be counted
on fingers, without resorting to thumbs) and simply get them to depend
on the new version.  The chain via ldb and similar is a pain, but now is
the time to do that.

We got the ABI wrong, and a new version with a new major version is the
right way to fix this, I think.  Perhaps we end up with the hack that
metze proposes, and a smaller bump, but that wouldn't indicate that we
think the old ABI is quite defiantly deprecated (and removed).

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

Talloc2 is what you sometimes get when a distribution can't rebuild and
must keep the old version around.  Often it's more talloc1, but the same
principal applies, but this is just a packaging workaround due to
uniqueness constraints.

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20090702/59dd3022/attachment.bin


More information about the samba-technical mailing list