On Sun, May 08, 2005 at 09:49:38AM +0100, Neil Williams wrote: > On Sunday 08 May 2005 12:20 am, Steve Langasek wrote: > > On Sat, May 07, 2005 at 01:24:31PM +0100, Neil Williams wrote: > > > Should I change the upstream version numbers of the existing library? > > No, why would you do that? It's the package name that's wrong (confusing) > > here, not the library name. > Sorry, that wasn't clear. I'll keep the source version at 0.5.2 (or possibly > 0.6.0) so that the source tarball will be qof-0.5.2.tar.gz - I meant should I > change the version numbers in the code to change the SONAME, library name or > other parts? You should change the SONAME and the package name IFF the ABI changes. > Also, if this is binary incompatible and I'm changing the name anyway, > should the Debian package for this shared library be libqof rather than > qof? Eh, if you mean the source package name, I don't see any reason to change it. > > The library soname, and the package name, are supposed to indicate *binary > > compatibility*, and nothing more. Their very *purpose* is to help people > > avoid recompiling their applications unnecessarily; embedding the upstream > > version number in either of these values thwarts this goal, because it > > forces people to recompile whether or not the new upstream version has > > same ABI. > So the question really is: As I've removed 17 deprecated functions and added > 60 new ones (out of 400), how can I assess if this is a sufficient change in > the ABI to warrant a new soname? > I'm guessing it is. It only takes one function being removed or changing its signature to break the ABI and require a new soname. > > > Are there tools for checking binary compatibility beyond just running an > > > existing program (which may not use all the functionality)? Anything I > > > can run from the source tree to indicate likely problems? > > Please see the icheck package. > Can't locate object method "get_expr" via package "CParse::Char" > at /usr/share/icheck/perl5/CParse/Enumerator.pm line 44. > Attempt to free unreferenced scalar: SV 0x8f5ea2c during global destruction. Well, that could be more useful. Would you mind filing a bug report against icheck about this? > I can't find CParse at CPAN, I'm not sure where this is going wrong. It takes > ages to scan a few files but never creates any output. CParse is part of icheck. -- Steve Langasek postmodern programmer
Attachment:
signature.asc
Description: Digital signature