If that one person isn't willing to deal with it then that person
shouldn't be writing libraries. :)
Never said that...
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. :)
Nor that. I merely meant that I understood why he chose this kind of SONAME.
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).
This goal of all this is to make the update of SONAME as far as I can
automatically.
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)
Alexis Papadopoulos
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]