* Alexis Papadopoulos (Alexis.Papadopoulos@imag.fr) wrote: > >>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. > > > The thing is that every change in a template class or function in the > shared library will lead to an ABI change (except some rare cases). > Since the majority of the modifications are made in this section of the > library I don't find absurd to modify the SONAME on each new compilation > of the library (only of course if modification has been made since last > compilation). You're sure the ABI for template classes is that sensitive? If it is then they probably shouldn't be in a library to begin with.. > This goal of all this is to make the update of SONAME as far as I can > automatically. That's almost certainly a terrible idea. > The idea now is to keep two records, one with the sources version and > one with the current soname. On each modification (and CVS commit) of > the sources, if changes have been made to the library's source files, > SONAME is increased, sources version is always incremented. The SONAME > will be (as inspired from libginac) in the following form : > lib*-X.Y.so.0.0.0 (the ending 0.0.0 because of libtool's usage) > or maybe lib*.so.XY (format that is used today by the upstream author) The SONAME needs to match across distributions so it really needs to be managed (and managed correctly) by upstream. If every change to the library requires an SONAME change then it almost certainly should not *be* a library. It would be rather disappointing if what you're saying about C++ template classes is really accurate. Personally, I suspect it's not. Thanks, Stephen
Attachment:
signature.asc
Description: Digital signature