Hi, I'm in the process of packaging Mapnik <http://www.mapnik.org/> and find myself in at the deep end trying to understand the way sonames and libraries names work (in general and in Debian -- to date my involvement has only been with binary-independent perl packages) and also how to deal with unstable (rapidly moving targets) libraries.
I've been referring to http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html and http://tldp.org/HOWTO/Program-Library-HOWTO/ but I'd like some additional advice, both for myself and upstream, who I am talking to. Mapnik consists of a C++ shared library with python bindings. Also included are some .so plugins but I don't believe that they are problematic currently; they can simply reside in /usr/lib/mapnik/ . Currently the picture is that upstream's build scripts make an unversioned shared library - that is, mapnik.so, with an soname of "mapnik". As I understand it, this isn's suitable for inclusion into Debian as is (at least as a shared library in /usr/lib; I understand that if I moved it into, say, /usr/lib/mapnik, I could arrange for the python bindings only to be available and pretend that the shared library was really private). However, this library is still in active development. I'm working with SVN snapshots at the moment because there hasn't been a stable release for a while. I've been trying to work out what to recommend to upstream in the way of sonames and library versioning but I'm not really sure where to go. I asked upstream the question of how many changes that would have required the soname to be bumped according to the points at http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html#AEN135 and he said around 10 since May. This seems like quite a high rate; if the package was released one a month, say, this would result in us already being on libmapnik.so.8... So my question is what should I request from upstream, and how should I go about packaging this best myself? Should it just go to experimental for now, and if so can I ignore the versioning requirement and package as is currently until upstream decide on sonames? Or should I package it as mapnik.so.0.0.0 and leave it like that until upstream makes their own soname scheme? Can I reconcile the fact that during development (between releases, in SVN snapshots) the interface may change in a non-backwards-compatible way but the soname won't change? Is there something fundamental that I've missed that would deconfuse me? Inspection of /usr/lib on my system reveals around 50 nonsymlinks of the form /usr/lib/*.so. Are these all bugs? eg: ./libdb-4.4.so ./liba52-0.7.4.so ./libdb-4.3.so ./libc.so ./libdb-4.1.so ./libdb-4.2.so ./libdb_cxx-4.2.so ./libdivxdecore.so ./libdivxencore.so ./libbfd-2.17.so ./libfakechroot.so ./libopcodes-2.17.so ./libgnomevfs-pthread.so [...] (I'm aware that a handful of these are LD scripts, but most aren't) Apologies for what has ended up being a rather rambly email. Any hints or tips, of course, gratefully received. Mapnik looks like being a very useful library for the GIS community and visible projects like http://www.openstreetmap.org/ are using it, so I would like to try and get it into Debian. Cheers, Dominic. -- Dominic Hargreaves | http://www.larted.org.uk/~dom/ PGP key 5178E2A5 from the.earth.li (keyserver,web,email) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
