[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Packaging a library when upstream does not build a .so

On Tue, Mar 17, 2009 at 10:17:37AM +0000, Enrico Zini wrote:

> I would like to get to the point of uploading #519184.  However I have
> one issue on which I'm unsure: the library API and ABI would be stable
> enough, but upstream is not building or supporting shared libraries yet.
> Last time I asked, he had some libtool problem in some obscure
> architecture and no time to investigate on it.
> Here are the possible options that I could think of:
>  1. Patch the package to build a shared library; I already have the
>     patch prepared and working.  What version should I pass to libtool?
>     0:0:0 is quite obvious, and hopefully when upstream will get to
>     shared libraries he will pick a higher one, but what if upstream
>     will break API or ABI once or several times before starting to
>     support shared libraries?  This is unlikely, but it cannot be
>     assumed to be impossible.

After some suggestions by Sune Vuorela on IRC, point 1 can be expanded:

 - call the shared library package libgribapi0d, adding the extra d to
   signify that it is a Debian specific shared library: that way, the
   name a future library provided by upstream will not conflict
 - at that point, I can do what I want with libtool versioning, starting
   at 0:0:0 and updating as needed as new versions progress

>  2. Package a -dev only package compiled with -fPIC, so that .so
>     language bindings can still link to it

I'll pick 1 unless I get significant objections.



GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <enrico@debian.org>

Attachment: signature.asc
Description: Digital signature

Reply to: