Hints on packaging a library

[Jonas Smedegaard]

On Thu, Aug 26, 2010 at 11:31:43AM -0400, Alexandre Quessy wrote:
>I was wondering if someone had hints on how to package a library. The 
>things I want to package are often distributed with at least an 
>executable which uses them.

My approach would be to suggest look at some library packages and try 
understand how each and every bit of information in them works.

...but it seems this is what you are doing already. :-)

Feel free to ask about bits and pieces of the packages I am involved in 
- I do try to have reasoning for every little comma in them, and would 
be happy to either clarify or be proven wrong (and then correct the bits 
revealed as being just casual or whatever).


>The packages I am working and contain libraries on are: scenic, 
>spinframework. I am also interested in packaging lyd.

Lyd? What is that? It is the danish (and norwegian) word for sound, but 
I never heard of it being a code project.


>For now, I used CDBS, but I would like to give a try to dh 7, to
>compare. :) Whatever works first...
>Any examples of packages I should check out?

As you might know by now, I only have CDBS examples :-)

Feel free to pick and interrogate me about any of the 140+ packages 
which contains libraries from this list: 
http://qa.debian.org/developer.php?login=dr@jones.dk

(in worst case you dig up something I haven't polished for some time, 
but that will be beneficial to the community to then get it straightened 
up - and perhaps you might learn something in that process too?)


>I looked at liblo, which is a library I know and use. It's pretty
>straightforward.

Yeah, that one is almost as simple as it can get.

The rules file of that one could be much simpler if I wasn't so fond of 
some modern CDBS surplus, and .install files could be slightly trimmed 
if (or when) switching to debhelper 7.  But apart from that, liblo is 
probably as it gets.

But beware - partly it has to do with the library itself being quite 
simple: There are not really any build-dependencies, so no development 
dependencies to keep track of.

A more realistic example is liblrdf - using d-shlibs, patching source so 
needing autotools reconfiguration (with the extra juggling it brings 
when not taking the easy route of agressive gitignore use).


>I found some info about the soversion (liblyd0, for example) in the
>Debian policy manual.
>http://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-shlibs
>There is no debian/shlibs file in the Git repo for the packaging of
>liblo. I guess it's generated by the debian/rules file?

That manual section describes how an shlibs file must end in the binary 
package, and that it _may_ end there by putting a similarly named file 
in the source package which then is installed with a debhelper script.

I prefer to resolve information dynamically whenever possible, and use 
d-shlibs for (most of) the library parts.  Might be that I got it wrong 
(I am certainly no expert in this area) but apparently the community is 
happy with e.g. uw-imap, libgd2, ghostscript, jbig2dec and other library 
packages that I maintain - none of which needs a shlibs file in the 
source package.


>It seems like the versioning of the shlibs rely on the
>LO_SO_VERSION=7:0:0 in configure.ac. Some project may not provide this
>upstream.

If upstream do not maintain SONAME properly then you have a coding 
issue, not just a packaging one.  You can patch code during packaging 
but packaging tools do not solve broken software, so don't look there 
for magic solutions to broken upstream code.


Kind regards,

  - Jonas

-- 
  * Jonas Smedegaard - idealist & Internet-arkitekt
  * Tlf.: +45 40843136  Website: http://dr.jones.dk/

  [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20100826/06d4fcfd/attachment.pgp>