On Saturday 07 May 2005 11:34 am, Steve Langasek wrote: > > When I read the Debian Library Packagaing Guide I get the impression > > that libnet6-1-0 would be correct, but some in #debian-devel said > > that the library is improperly named. Upstream's intention for â- > > release 1â was that major versions are binary incompatible anyway and > > so one could reset the SONAME to 0:0:0. If this versioning should be > > changed upstream please tell me so, and please with a clue for me > > what's wrong with it. Otherwise please give me a package name with > > which the package could be added to Debian. > > 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? How? 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. Personally, I don't think it's ready for a v1.0 release, there is still work to be done for that. 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? My ITP for my own project using QOF: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=305563 (An application, not a library. Currently 0.0.3 in CVS, 0.0.2 release.) My work on QOF: http://www.linux.codehelp.co.uk/#qof Current downloads: http://sourceforge.net/projects/qof http://sourceforge.net/projects/pilot-qof Current CVS: http://cvs.sourceforge.net/viewcvs.py/qof http://cvs.sourceforge.net/viewcvs.py/pilot-qof -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
pgp9f1HyaWvqL.pgp
Description: PGP signature
