[pkg-fso-maint] shared library in binary-package?

[Steve Langasek]

On Sun, Sep 06, 2009 at 08:48:50PM +0200, Heiko Stübner wrote:

> as I was unsuccessful in finding similiar cases on the mailing lists I would 
> like some input on the handling of corner-case in packaging.

> The package is fso-usaged from the freesmartphone.org software-stack and not 
> yet in debian.

> Compilation results in a binary fsousaged, a shared library libfsousage.so* 
> and three plugins (controller.so, lowlevel_kernel26.so, lowlevel_openmoko.so).

> The plugins use libfsousage and fsousaged loads them according to its config-
> file.

> According to the debian-policy libfsousage would require the two separate 
> shared libary packages (0, -dev) but the only users are and will be fsousaged 
> and the plugins alone.

> Are there other packaging options for such a case, as libfsousage is currently 
> 3,4KB and it seems like much overhead to have the library-packages when there 
> won't ever be other users of it.

> Currently I have all in one package (34KB deb / 252KB installed-size) but 
> lintian doesn't like it.

> Any pointers would be greatly appreciated.

I'm not sure Policy actually provides an exception for this case, but here
are a couple things you should take care of if you're going to ship a
private shared library in a package:

 - Don't ship anything that would belong in a -dev package.  Since you're
   not supporting it as a shared library package, you also shouldn't be
   allowing other software (packaged or local) to link against it.  If you
   think this is something you need, that's an argument for providing a
   proper shared library package.

 - Make sure you don't provide shlibs.  The only reason to have a shlibs
   file is so that packages can declare a dependency on the shared library;
   since there shouldn't be anything doing this, having the shlibs will only
   invite accidents.

I agree with the other comments that for this use case, it would be better
to just statically link the library into the daemon and let the plugins
resolve symbols against it.  While there's an architectural cleanliness to
having a shared library that both daemon and plugins link against, and it
enables use of things like LDFLAGS=-Wl,-z,defs to ensure you never have
plugins with accidentally missing symbols, I don't really think it's worth
the tradeoff of maintaining a proper shared library.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek at ubuntu.com                                     vorlon at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-fso-maint/attachments/20090907/620dd95f/attachment-0001.pgp>