[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