Re: freeze exceptions: qpdf, tiff
Julien Cristau <jcristau@debian.org> wrote:
I hope you will not take it the wrong way that I'm continuing to argue
this point. We share a common goal of ensuring that this change is safe
and will not cause problems, and I appreciate that you have to act in a
policing role about this issue. I also appreciate that many developers
don't understand the subtleties of what constitutes a breaking ABI change.
In the case of qpdf, it seems as though we disagree on whether the
changes are safe. If I have made a mistake, I will surely correct it,
but at this point, I still don't believe that I have introduced an
incompatible change to the library's ABI, and I really don't want to
artificially and needlessly increase the SONAME as that is disruptive to
my users. So I continue the discussion below.
>> > I see new API but no shlibs bump?
>>
>> New API doesn't require a shlibs bump. Changed or removed API requires
>> a shlibs bump.
>
> Err. New API is what shlibs is for. Changed or removed API requires a
> SONAME and package name change.
How is what you're saying different from what I'm saying? I interpreted
"shlibs bump" to mean changing the SONAME. Do you mean something
different? You say "Changed or removed API requires SONAME and package
name change", and I agree. But I don't believe that I have introduced
any changed or removed API. Adding new API is not a reason to increase
the SONAME. This happens all the time.
The reason for this is that the SONAME needs to change when there's a
reason that OLD applications linked originally with the OLD library
can't continue to work with the NEW library. In other words, you should
be able to upgrade the shared library without breaking existing
applications. Having new callable methods appear in the shared library
will not interfere with existing applications as long as existing
symbols can be resolved in the same way.
There's no expectation that executables linked with the new library will
work with the old library. That's why adding new API doesn't require
changing the SONAME.
Do you disagree with my understanding of when the SONAME has to change,
or do you disagree with my analysis that none of the things that require
an SONAME change have happened? Or have I just done a poor job of
explaining why my changes are compatible and have unwitting led you to a
false conclusion?
If our communication is clear but we disagree on one of these issues,
can we get someone else to weigh in? Isn't this what the technical
committee is for?
A good discussion of this issue can be found here:
http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html
Fundamentally though, you can usually tell by comparing the header files
and the list of exported symbols from the libraries.
The only changes that could even possibly be considered worthy of
causing an SONAME change are the addition of two new private data
members to the end of QPDF_Stream and the change to a private member
function of QPDFWriter. However, QPDF_Stream is a private class to the
library: its header is not installed, no actual instances of the class
are ever exposed to the users of the library, and no classes are derived
from QPDF_Stream. Therefore, addition of new data members to the end of
the object can't cause breakage of existing applications. And the
method that changed in QPDFWriter is private. It can't be called from
outside the QPDFWriter class, so this is safe too. If there's any
doubt, you can run nm -D --demangle on the old and new shared libraries,
observe that the only method that disappeared from the old is
QPDFWriter::disableIncompatbleEncryption(float), and then verify by
looking at QPDFWriter.hh in 2.1.5 that this was in fact a private
method.
I designed QPDF's APIs the way they are in significant part to make it
possible to make certain types of changes without breaking binary
compatibility.
--
Jay Berkenbilt <qjb@debian.org>
Reply to: