> From my point of view this is a valid compromise: In the
> shipped versions of talloc just warn that something is
> wrong. The message should carry a warning that potentially a
> leak was created. If a developer wants to reproduce this
> [s]he is free to use a "checked build" version of the
> application, compiled against the "location"-aware talloc
> headers and .so.
That would mean we're back to the problem of two versions of talloc in
the same binary, one with 'checked build', one without.
> This way we don't have to break anything and just increment
> the minor version number due to talloc_reparent being added.
nope, I am not going to let the shared library force me into a
situation where I can't improve talloc when I think that improvement
Adding the error messages is a worthwhile improvement. I'm not going
to compromise on code quality over this silly focus on a set of shared
libs used by a handful of apps, all of which currently use the libs in
a completely broken way.
I am also going to continue to make further improvements to talloc as
they come up. If that means we need to change the .so number to 3, 4
or even 37 in the future then so be it. That is what the .so number is
I think the same principle should apply to all the shared libs that
are currently being exported from Samba by various people. We are
certainly going to be making improvements to libtdb, libdcerpc,
libndr*, libldb and all the other libs over the years. To start
compromising on the quality of the code in Samba in order to keep
those libs from changing version number is a classic case of the tail
wagging the dog.
The people who package the libs, such as Simo does for RedHat, are of
course free to put whatever hacks they like in their own versions. If
he wants to add symbol versioning or backwards compatibility hacks
then that is completely up to him. That is part of the life of library
maintainers. It is not reasonable to push those hacks on the upstream