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

Re: Tricky library packaging question

Hi Enrico,

On Mon, May 09, 2005 at 03:06:28PM +0200, Enrico Zini wrote:

> Now, the ABI, and to a lesser extent the API of the libraries is still
> not stabilised, so I was planning to package libtagcoll1 and libdebtags1
> only as -dev packages.  That way, packages would be statically linked to
> them and a new version of the libraries wouldn't break existing
> packages.  Something similar is being done with libbuffy-dev and buffy,
> and buffy also has this build-depends line to work a bit around
> unexpected FTBFS:
>   Build-Depends: ..., libbuffy-dev (>> 0.3), libbuffy-dev (<< 0.4)
> this is suboptimal and requires some coordination between the library
> and its users, but it's ok while there are not many applications using
> the library.

> Libbuffy also has python bindings.  I could not build them with a
> package build-depending on libbuffy-dev, as that would not contain PIC
> code and the python bindings are shared objects.  So I build them as
> part of libbuffy-dev, directly pointing at the .lo files built by
> libtool during the compilation.

> Now comes libdebtags.  I'm doing the same, however I also depend on
> libtagcoll1, which is -dev only (and thus not PIC).

> How do I handle all this?

> Option 1:
>  - Generate shared libraries, with a shlibs file creating dependencies
>    for an exact version, and put in the description that they are
>    there only to compile the bindings and should not be linked against.

> Option 2:
>  - Generate -pic packages.  Here I need some practical help because I've
>    never done it.

> I cannot think of any other options.  I'm short of clues for the best
> way of doing this, and I'd be happy to give access to the svn repository
> of people who could help and work on it together.

I imagine these libraries are fairly small, and therefore IMHO there's no
real reason to create a separate -pic package for each.  However, you do
need to provide the library in PIC form if you're going to be linking to it
from other packages that provide DSOs (i.e., perl and python modules).  I
would suggest simply bundling a libfoo_pic.a (static, PIC) library in the
respective -dev package.

Steve Langasek
postmodern programmer

Attachment: signature.asc
Description: Digital signature

Reply to: