[Debtags-devel] Re: Tricky library packaging question

[Steve Langasek]

--idY8LE8SD6/8DnRI
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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
=66rom 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.

Cheers,
--=20
Steve Langasek
postmodern programmer

--idY8LE8SD6/8DnRI
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFCgCgKKN6ufymYLloRAqQbAKC2mYSPP/fA9ZCnLX9inIgo85gU/wCgn4ax
dXpPtoWIm6jnm2GInceW/hQ=
=zePP
-----END PGP SIGNATURE-----

--idY8LE8SD6/8DnRI--