Re: freeze exceptions: qpdf, tiff
On Sat, Aug 21, 2010 at 12:00:54 -0400, Jay Berkenbilt wrote: I will fix it, re-upload, and re-request a freeze exception. 2.2.0-2 unblocked. Cheers, Julien signature.asc Description: Digital signature
Re: freeze exceptions: qpdf, tiff
Julien Cristau jcris...@debian.org wrote: On Fri, Aug 20, 2010 at 16:27:13 -0400, Jay Berkenbilt wrote: For qpdf, this is a new upstream version that is binary compatible with the old one. qpdf is isolated in the dependency tree (no other packages depend on it), and I am upstream, so I can definitely vouch for the fact that the changes were relatively minor and should be very safe. I see new API but no shlibs bump? New API doesn't require a shlibs bump. Changed or removed API requires a shlibs bump. 2.2.0 adds several new functions. The only function that changed incompatibly was QPDFWriter::disableIncompatbleEncryption(float), which is a private method in the QPDFWriter object. No external code could call that method, so it can't be an unresolved symbol anywhere, so changing it does not require a shlibs bump. I use libtool to manage the shlibs. CURRENT,REVISION,AGE for 2.2.0 is 4,0,1. For 2.1.5, it was 3,4,0. This is consistent with new API having been added but no callable API having been changed or removed. To be absolutely certain, I built qpdf 2.1.5 from source, swapped its native libqpdf.so.3.0.4 with a copy of libqpdf.so.3.1.0 (renamed to libqpdf.os.3.4), and ran qpdf's very thorough test suite. The 2.1.5 qpdf's test suite passes when run with the 2.2.0 qpdf's shared library with the exception of the fact that the test suite reports incomplete coverage on the new API (which is, of course, not exercised by the 2.1.5 test suite). So (assuming you trust the thoroughness of the qpdf test suite), this also confirms that the ABI has not been broken. Are you seeing something different from this? If so, please let me know. I'm also interested to know what you're using to determine whether there are ABI changes. Thanks for being so thorough. -- Jay Berkenbilt q...@debian.org -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100821090836.0290813736.qww314...@soup
Re: freeze exceptions: qpdf, tiff
On Sat, Aug 21, 2010 at 09:08:36 -0400, Jay Berkenbilt wrote: Julien Cristau jcris...@debian.org wrote: On Fri, Aug 20, 2010 at 16:27:13 -0400, Jay Berkenbilt wrote: For qpdf, this is a new upstream version that is binary compatible with the old one. qpdf is isolated in the dependency tree (no other packages depend on it), and I am upstream, so I can definitely vouch for the fact that the changes were relatively minor and should be very safe. 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. Cheers, Julien signature.asc Description: Digital signature
Re: freeze exceptions: qpdf, tiff
Julien Cristau jcris...@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 q...@debian.org -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100821105320.0290889916.qww314...@soup
Re: freeze exceptions: qpdf, tiff
Seems we're just talking past each other. On Sat, Aug 21, 2010 at 10:53:20 -0400, Jay Berkenbilt wrote: I interpreted shlibs bump to mean changing the SONAME. Do you mean something different? I wasn't talking about the library's SONAME, I was talking about the shlibs control file from your package (as documented in policy §8.6, and used by dpkg-shlibdeps). Cheers, Julien signature.asc Description: Digital signature
Re: freeze exceptions: qpdf, tiff
Julien Cristau jcris...@debian.org wrote: Seems we're just talking past each other. On Sat, Aug 21, 2010 at 10:53:20 -0400, Jay Berkenbilt wrote: I interpreted shlibs bump to mean changing the SONAME. Do you mean something different? I wasn't talking about the library's SONAME, I was talking about the shlibs control file from your package (as documented in policy §8.6, and used by dpkg-shlibdeps). AH! (*strikes head on forehead*) Oops... Thanks for catching that. My mistake. I so thoroughly missed the point that I interpreted shlibs bump as SONAME change. Of course shlibs makes sure you have a new enough version of the library package. I will fix it, re-upload, and re-request a freeze exception. Thanks for setting me straight, and sorry for the confusion. -- Jay Berkenbilt q...@debian.org -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100821120054.0290808079.qww314...@soup
freeze exceptions: qpdf, tiff
I'd like to request two freeze exceptions: qpdf 2.2.0-1 and tiff 3.9.4-3. For tiff, there are no code changes from 3.9.4-2. I just fixed up requires, conflicts, etc., to bring it up to standards 3.9.1. (I didn't want to combine that with the security fix that was in 3.9.4-2 and was uploaded with urgency=high.) For qpdf, this is a new upstream version that is binary compatible with the old one. qpdf is isolated in the dependency tree (no other packages depend on it), and I am upstream, so I can definitely vouch for the fact that the changes were relatively minor and should be very safe. Thanks for your consideration. -- Jay Berkenbilt q...@debian.org -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100820162713.2402820247.qww314...@motoko.argon.local
Re: freeze exceptions: qpdf, tiff
On Fri, Aug 20, 2010 at 16:27:13 -0400, Jay Berkenbilt wrote: I'd like to request two freeze exceptions: qpdf 2.2.0-1 and tiff 3.9.4-3. For tiff, there are no code changes from 3.9.4-2. I just fixed up requires, conflicts, etc., to bring it up to standards 3.9.1. (I didn't want to combine that with the security fix that was in 3.9.4-2 and was uploaded with urgency=high.) Unblocked. For qpdf, this is a new upstream version that is binary compatible with the old one. qpdf is isolated in the dependency tree (no other packages depend on it), and I am upstream, so I can definitely vouch for the fact that the changes were relatively minor and should be very safe. I see new API but no shlibs bump? Cheers, Julien signature.asc Description: Digital signature