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

Re: How package a binary library with unversioned soname?



Nikolaus Schulz <microschulz@web.de> writes:
> On Mon, Oct 01, 2007 at 05:35:36PM -0700, Russ Allbery wrote:

>> While with non-free software you can't really change the binaries, you
>> definitely *can* change the packaging structure however you'd like.
>> Does it make sense to have six different packages?  Or is this really
>> one thing that should be shipped as a single package?

> Wouldn't merging the packages require some patch management system?  I
> hoped to get along without such a thing. 

It would require that you make modifications to the upstream source,
probably.  So will lots of other things, though.  The only packages for
which I don't end up needing some sort of patch management system or
strategy for modifying the upstream source are ones for which I'm
upstream.

> How big?  Byte-wise they're small, my current GPL deb's are <100k each.
> The binary library packages eat 700k for one printer series.

It sounds like between that and the separate binaries for different
printing systems, it would be useful to separate things out into separate
packages.

I personally am not particularly uncomfortable with shipping binary
packages that use RPATH to find libraries in a subdirectory of /usr/lib,
provided that they have a tight dependency on exactly the version of the
library package they need (which for this application you'll probably need
anyway).  Other people may differ.

> Hmm, I guess I should mention another problem.  Unfortunately one of
> these binary libraries has a path hard-coded: it expects private data
> files in /usr/lib/bjlib.  I'm not sure, is this fatal?  What is the best
> course of action here?

What sort of private data files?  At least at first glance, that doesn't
seem unreasonable, as long as it doesn't expect to do something like write
to the at path.

This pile of code does sound like a rather spectacular mess, though, so
it's worth thinking long and hard about whether Debian really needs it.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>



Reply to: