* Alexis Papadopoulos (Alexis.Papadopoulos@imag.fr) wrote: > >It's a single headache for the one library developer/packager, as > >opposed to headaches for _every user_ of the library. > > > Yes indeed, but it's still a headache for one person ;). If that one person isn't willing to deal with it then that person shouldn't be writing libraries. :) > I will take a look into debian-mentors, but I've just talked to the > upstream author and can now explain the reason of his choice. Unfortunately that doesn't make his reasoning right. :) > The thing is that the library is written in C++ and makes heavily use of > templates which means that even a small change in the code, that doesn't > change the ABI, might lead to incompatibility. There's no 'might' about it... Either it changes the ABI or it doesn't. ABI does mean more than just symbols though and so, yes, you do have to be careful and realize when you make an ABI change. > We therefore checked the existant libraries coded in C++, using > templates and present in the debian distribution. We only used two > examples, libginac and libboost-python. We looked both of the shared > libraries present : > libginac-1.3.so.0.0.0 with SONAME libginac-1.3.so.0 : the version is > contained in the SONAME which means that if a program is linked against > libginac-1.3 and only libginac-1.4 is present on the system, it will fail. Generally this is done when there's an API change (which also implies an ABI change) that is pretty significant such that programs written to work with the old API will have to be updated/significantly modified. The expectation is that there would be, in the above case, point releases such as '1.3.1' which would be API-compatible, and if ABI-compatible then the SONAME wouldn't change, and if not ABI-compatible then it would change. Thanks, Stephen
Attachment:
signature.asc
Description: Digital signature