[QUICK] talloc bugs

[simo]

On Wed, 2009-07-01 at 22:53 +1000, tridge at samba.org wrote:
> Hi Simo,
> 
>  > So, no, not all APIs or ABIs inside samba are changeable at will at this
>  > point. That doesn't mean they are locked down, just that a change that
>  > breaks the API contract or the ABI interface need to be evaluated and
>  > agreed upon in advance and decisions need to be made on whether this
>  > warrant creating a new set of libraries (basically a fork and rename of
>  > symbols), or whether the extensions required can be done without
>  > breaking existing code.
> 
> That is the job of the shared library package maintainer, not us. I
> know that you and Jelmer have been doing the work behind that library
> maintainence, but that is not a reason to prevent ABI changes within
> Samba.

Nobody proposed a code freeze if that's what you are thinking, but there
is a big difference between parts of samba that are inherently internal
and parts that are shared with other projects.

> We make changes that affect the ABI in the libraries used in Samba all
> the time. To constrain ourselves to changes that do not change the ABI
> would be a huge (and ever increasing!) burden. 

No, it is not, it only requires a bit of care and attention to the ABI,
I've been doing it for months now and it is working quite well. I've
also added tools in the standalone build to make it easier to catch
involuntary changes.

> The person who packages the code into shared libs needs to change the
> version number on that shared library when the ABI changes. That
> packaging of the shared library (with versioning) is not done inside
> the Samba git tree, and I very much hope it stays that way.

You are wrong, versioning is totally in git, samba3 checks the version
of talloc as well as tdb and tevent at configure time, and releases have
been made from git. We committed to stable API/ABI for these libraries
like we did for libsmbclient, we can't take our word back now that other
projects started using our libraries.

It's not just a matter of version change, it's a matter of symbols and
upgradeability. Fact is that we released this code and other people
depends on it, the least we can do is to avoid unnecessarily breaking
code. It can be done, it just requires a bit of care.
I can help changing the code so that we do not break the ABI.

> As regards to the API changes I made (disallowing some previously
> ambiguous operations), that is a bug fix. Disallowing previously buggy
> usage is quite normal between versions of libraries as far as I know,
> just like bug fixing is normal between library versions.

There are many ways to do that, as you can see in the code
talloc_refernce() was already marked as deprecate, so changing behavior
around it is ok for me (either remove it or transform it).
But we don't need to break the rest of the code.

> The shared library package maintainer might decide to change the major
> version as a result, and that would be a perfectly valid reaction, but
> to say we can't change code inside Samba is far too constraining on
> the project.

Nobody is proposing to halt changes. But there are changes for which
breaking the ABI does not make much sense, I think this is the case.

Simo.

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