On Tue, 1 Jan 2008 23:17:50 -0800 Steve Langasek <vorlon@debian.org> wrote: > On Wed, Dec 26, 2007 at 01:11:40PM +0000, Neil Williams wrote: > > I think I'm doing this already - if libfoo1 implements and exports types > > from libbar2 and libbar2 moves to libbar3, I would expect to have to > > port libfoo to libbar3 and this would usually cause a SONAME bump in > > libfoo. > > Have I got these possible scenarios correct: > > > 1. libfoo depends on libbar2 without exporting libbar symbols. libfoo > > can migrate to libbar3 with internal code changes and if these do not > > require changing any libfoo interfaces, libfoo needs no SONAME bump. > > No, "exporting libbar symbols" is not the right line to draw. The right > line is the one I already identified, namely, "libfoo uses some of libbar's > types in its own exported ABI". That makes more sense, thank you. > > Does libfoo need to use versioned symbols to cope with this > > No, libbar does, as the library which has other libraries for > reverse-dependencies. (codehelp has a light bulb moment of clarity). :-) > > 2. libfoo depends on libbar2 and exports some libbar symbols in > > libfoo-dev. libfoo can migrate to libbar3 with only internal code > > changes because it only exports a portion of the libbar API that has not > > actually been changed in the libbar2->libbar3 transition. libfoo needs > > to export libbar in the libfoo --libs data. Is a SONAME bump needed in > > libfoo even though *none* of the libfoo interfaces have changed? As > > upstream for libfoo, I would not normally make a SONAME bump in this > > situation. > > If libfoo's exported ABI hasn't changed, then any package name or soname > change is gratuitous and should be avoided. Agreed. > > 3. libfoo depends on libbar2 and needs to make changes to its own > > interfaces to cope with the libbar transition or needs to export symbols > > from the new libbar API and therefore makes a SONAME bump. No problem > > here except ensuring that applications transition to both API's at the > > same time. Can be enforced by making libbar-dev conflict with the old > > libfoo-dev or making the new libfoo-dev depend on the new libbar-dev > > version. > > Requires disruptive name changes to libbar-dev which affect all packages > that build-depend on it, and is therefore again inferior to implementing > symbol versions up front. OK. > Because *all* libraries which have other libs as reverse-dependencies should > implement symbol versioning, precisely as the shortest path for reliably and > permanently addressing the various issues we're discussing. > > It *is* libbaz's fault for having an ABI-breaking change. And based on > history, it is only reasonable to assume all such libraries are guilty, and > demand that they use symbol versioning in anticipation of such future ABI > changes. OK, I'm doing this upstream for one of my packages - following threads from: http://lists.debian.org/debian-mentors/2007/05/msg00387.html http://www.gnu.org/software/binutils/manual/ld-2.9.1/html_node/ld_25.html That gave me a basic versioning addition to the library, a diff of objdump -p shows: +Version definitions: +1 0x01 0x06077991 libqof.so.1 +2 0x00 0x0f307023 LIBQOF_0.7.3 + (I'm not putting the history of the symbols into the file at this stage - no new symbols are added in the new version so the libqof.ver file is simply marking all as global. I could add historical data - is there any benefit in that?) That's upstream covered, it appears I also need debian/libqof1.symbols from http://qa.debian.org/cgi-bin/mole/seedsymbols ? If I had done symbol versioning correctly upstream, shouldn't dpkg-shlibdeps be able to create the necessary data itself? I don't provide a .shlib file of my own at this stage. (A SONAME bump is due in this library fairly soon so I want to get symbol versioning into libqof1 prior to the ABI change.) > No. You seem to agree that each soname change of a library near the bottom > of the stack should not propagate its way up the stack to affect other > libraries that themselves are not affected by the ABI change, but you again > overlook (or disdain) the impact that this has on partial upgrades if we > don't require those base libraries to use symbol versioning. It was an oversight. Sorry. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgpaILUyGB9CK.pgp
Description: PGP signature