Re: Library sonames and unstable libraries
On Fri, Jan 05, 2007 at 01:25:56PM -0700, Hubert Chan wrote:
> On Fri, 5 Jan 2007 17:56:17 +0000, Dominic Hargreaves <email@example.com> said:
> > 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/ .
> Remember to read the Python policy for the Python-related bits.
Yup, thanks :)
> > 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.
> >From the webpage, the last release was last May, which is just over half
> a year ago, which isn't really that long ago.
> In general, it's probably a bad idea to package SVN snapshots of a
> library that changes ABI so quickly, since every ABI bump requires a new
> binary package name in Debian.
Hmm. Well, I sill encourage upstream to make a stable release before too
long, but there's no point in doing that if he's not sure how to version
> One other option, if you really must use the SVN snapshots, is to make
> it a statically linked library. However, there are several concerns
> related to static linking, so it should be avoided whenever possible.
Assuming that I want to publish some at least partially useful packages
(for a start, much of the use will be via python bindings rather than
linking against the .so) until upstream has committed to an soname
policy, and made a stable release, would it be acceptable to use
experimental for this (ie where the package is otherwise policy-clean
but doesn't have clean soname bumps during the tracking of SVN
snapshots) or should I stick to having this in my private webspace
(and losing autobuilding, bugtracking and other bits and pieces of
Dominic Hargreaves | http://www.larted.org.uk/~dom/
PGP key 5178E2A5 from the.earth.li (keyserver,web,email)