[SCM] Samba Shared Repository - branch master updated -
jra at samba.org
Wed Jul 1 22:45:22 GMT 2009
On Thu, Jul 02, 2009 at 08:14:11AM +1000, tridge at samba.org wrote:
> Hi Jeremy,
> > What about Metze's suggestion, wouldn't that keep the bugfix
> > without breaking the ABI ?
> It's a neat idea certainly, but I wonder how long we have to keep it
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.
> It isn't completely without cost, as it creates a new trap for
> programmers. If someone forgets to #include <talloc.h> in some module
> in their application but they use these parts of the talloc API then
> they will not get a compile/link error, they'll get these ABI
> compatibility functions. In this case the two functions are very
> similar, so it would probably cause very few problems, but if we ever
> want to get rid of these ABI compat functions then we'll need to bump
> the soname number anyway.
Yes - that's the point. You got rid of them without
bumping talloc to talloc.so.2. 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.
> I don't want the tail wagging the dog in Samba. I don't want the fact
> that some of our code is used in shared libraries to constrain the way
> we develop Samba, and how we fix bugs. With .so numbering we don't
> need to be constrained and we can fix bugs in the best way we can
But we've released this library. We've gotten people using it
in other applications. This isn't only our code anymore.
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.
If this were a larger change, which warrented talloc2,
then I'd agree. 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.
More information about the samba-technical