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...@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
signature.asc
Description: Digital signature
_______________________________________________ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers
