the sorry saga of the talloc soname 'fix'

[tridge at samba.org]

Hi Steve,

If the symbol versioning can be done outside of the core code, then
fine. It could be in a lib/talloc/packaging/ directory for example. If
needed then that directory could even have a patch in it that modifies
talloc.c if that is absolutely required.

The problem I see with symbol versioning is that it is so system
specific and so complex to maintain. Symbol versioning on Solaris
(where it was invented) is different to symbol versioning on
Linux. From reading the treatise on shared library maintenance by
Ulrich Drepper it seems that symbol versioning even has architecture
specific aspects to it within Linux.

So to me it should not go in the core code. If you think it needs to
be in a common place so that deb and RPM based distros coordinate,
then put it in a packaging/ subdirectory.

In all of this please also remember just how much of the Samba
codebase is now in shared libs. The librpc code alone is over 500k
lines of code, including the generated code. That lib is used by
external projects, and may be called both directly and indirectly by
apps, just like talloc is.

Whatever method we establish for handling shared libs now is not just
for talloc. It applies to a very large proportion of the projects code
base. I do not want that entire code base constrained by external
shared lib concerns. I do not want the maintenance of the shared lib
ABI to become the responsibility of every contributor to Samba. 

Cheers, Tridge