On Sat, Jul 10, 2010 at 12:36:14PM -0700, Steve Langasek wrote: > It's not that these libraries will never have incompatible ABI changes, it's > that they encode the ABI information in a non-standard way - the '4' in > libnspr4 and the '3' in libnss3 do represent the sover, they just do it in a > manner that's gratuitously incompatible with how all other Unix libraries > have been versioned since time immemorial. > > If we're going to relax the rules for sonames, I think they should be > relaxed only to accomodate this particular case of the so version being on > the lefthand side of the .so extension with no delimiter before it. I.e., > let a shlibs file of 'libnspr 4 libnspr4-0d' do the right thing, but don't > allow shlibs files with an empty version field.
I'm not totally sure it would be a good idea to modify shlibs to work that way, and it would somehow feel wrong that a library you link with -lnspr4 is described as libnspr and not libnspr4 in the shlibs. I just think the rule should be relaxed, but the implementation should be done with symbols files. BTW, are there any other libraries with the same problem, where compatibility with other distros may be important? (which btw, in the case of nss and nspr, is even more important since part of these libs are part of the LSB, which is why the .so symlinks are in the library package and not the -dev package ; but it would still be better that binaries built on debian could work on other systems, too, which is not the case atm) Cheers, Mike -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
