Library sonames and unstable libraries
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)
Reply to: