On Sat, May 07, 2005 at 01:24:31PM +0100, Neil Williams wrote: > > Setting aside any questions of how upstream *should* version their > > libraries, here is a shell snippet that spits out the "best practices" > > package name for any given library: > > $ objdump -p /path/to/libfoo-bar.so.1.2.3 | sed -n > > -e's/^[[:space:]]*SONAME[[:space:]]*//p' | sed -e's/\([0-9]\)\.so\./\1-/; > > s/\.so\.//' > I've got my own package (with sponsor) to upload at some point but it depends > on the current CVS version of an existing library. I'm a developer on that > project (and co-maintainer) and I can change the upstream code. The above > snippet produces a different package name (which I expected as the current > package name isn't intuitive). > 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. > What version should I use for the next release? > If I change the upstream, what is the best way to show that this is the next > release after 0.5.0? > What implications might this have for programs that use the library or other > distributions? > $ apt-cache search libqof > libqof-0.5.0-1 - Query Object Framework > libqof-0.5.0-1-dbg - Query Object Framework - debug symbols > libqof-dev - Query Object Framework > $ objdump -p ./libqof.so.1.0.0 | sed -n > -e's/^[[:space:]]*SONAME[[:space:]]*//p' | sed -e's/\([0-9]\)\.so\./\1-/; > s/\.so\.//' > libqof1 > I'm currently working with it as v0.5.2 - that release will add functionality > but retain the existing code - I'll have to check binary compatibility but > existing functions have not been changed and nothing (except a few already > deprecated #define's) in the old API has been removed. Modifications have > been kept to adding new functions and updating the internal code within old > functions. I'll soon be testing compatibility with the help of the current > maintainer for libqof. 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. However, once an soname (or package name) has been chosen for a particular ABI, even if you decide that it wasn't the best name, you should *not* change it until the ABI changes again -- otherwise, you're again forcing people to recompile against the new version when they don't have to! So if upstream version 0.5.2 is still binary-compatible with 0.5.0, Then qof 0.5.2's library should continue to be called libqof.so.1, and the package should continue to be called libqof-0.5.0-1. If it's *not* binary-compatible, *then* you should change both the soname and the package name, and hopefully make them match at that time: i.e., libqof2 and libqof.so.2. > 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. It's not going to be included in sarge per the request of the maintainer, so you can't use it as a build-time check in any sarge packages, but it should help you check function signatures for C libraries in more detail than is available from the compiled libraries. You can also use objdump -T and diff to compare the list of exported symbols in the actual binaries. I recommend using both objdump -T and icheck together for checking whether the ABI has changed. -- Steve Langasek postmodern programmer
Attachment:
signature.asc
Description: Digital signature