Re: Packaging a library when upstream does not build a .so
* Enrico Zini [Wed, 18 Mar 2009 11:42:58 +0000]:
> On Tue, Mar 17, 2009 at 03:03:22PM +0000, Simon Huggins wrote:
> > Is there a reason you need this now and can't wait until you've managed
> > to argue for the shared library from upstream and cajoule them into
> > producing a .so?
> > I had an upstream that wasn't very confident with soname changes and
> > went through a long process explaining that and the benefits but
> > ultimately it was worth it.
> Upstream will not be able to tackle shared libraries before an
> unpredictable amount of time, which could easily exceed one year or two.
> I am trying to help by sending him an up-to-date version of my libtool
> patch after every release, and making myself available for any other
> help that would be needed. However, he is not evil; he has other much
> more urgent things to work on.
> In the meantime, should I:
> - not package the library, which is however very useful, and needed by
> other software that I have written and want to package
> - package the library only as a -dev built with -fPIC (but no one has
> endorsed that option so far)
> - package a debian-only shared library, taking advantage of the fact
> that API and ABI are rather stable, and have been for a year. In
> that case, I need to figure out the best way to do it.
I think you should go for #3, package a shared library with a Debian
My preference would be for libfoo.so.0d, libfoo.so.1d, ... (package
names libfoo0d, libfoo1d, ...), but it’s probably not worth your time to
investigate how to achieve that with libtool, so libfoo-0d.so.0,
libfoo-1d.so.0, etc., also sound appropriate and easily achieved with
the -release option for libtool as Roger Leigh hinted (keeping
-version-info always at 0:0:0). Package names would be libfoo-0d-0,
- Are you sure we're good?
-- Rory and Lorelai