Re: upstream library without a SONAME
On Wed, 25 Jul 2001, Steve M. Robbins wrote:
> On Wed, Jul 25, 2001 at 03:50:47PM -0500, Steve Langasek wrote:
> > On Wed, 25 Jul 2001, Steve M. Robbins wrote:
> > > So I guess I'm still searching for the answer to my original questions:
> > > 1. Does Debian require a SONAME for a shared lib?
> > Yes, although this may not be spelled out clearly in policy. [...]
> > > 2a. If so, what to do about upstream packages that don't supply one?
> > I would suggest that it's a maintainer's responsibility, as liaison
> > to the upstream developers, to petition them to adopt SONAMEs in any
> > shared libraries they provide that will be linked by external
> > applications.
> While I agree with you, and have started the petitioning process, I'd
> still really appreciate suggestions on what SONAME to use for the
> package between now and such time as upstream adopts a SONAME.
> I could arbitrarily start with SONAME libInventor.so.0, and fix up the
> packaging with an epoch if I get stuck later. Or, since the source
> version is 2.something, I could start with SONAME libInventor.so.2.
> Or is the correct approach to just embed the entire source version
> in the SONAME, i.e. libInventor.so.2.1.5-7 (yes, upstream source
> version ends in -7)?
I think an SONAME of libInventor.so.0 is best for starting. It's too late to
fix previous releases of the software if they didn't include SONAMEs, and the
SONAME is expected to NOT follow the source version, so you may as well start
now with a major number of 0 and go from there.
If it takes a while to persuade upstream to start using sonames, you may even
have to take the initiative to increment the so major number on your own
(worst case).
> These are perfectly good shared libs, in the sense that I can
> link against them:
> steve@riemann{steve}ldd /usr/bin/ivview |grep Inventor
> libInventorXt.so => /usr/lib/libInventorXt.so (0x40026000)
> libInventor.so => /usr/lib/libInventor.so (0x400b8000)
> I gather from Steve L's response that he would consider these packages
> to be in violation of policy, however.
If you could guarantee the ABI would never change, I would say it's not a
policy violation. :) The problem comes when the library symbols /do/ change,
and there is no clean upgrade path.
Example:
application foo links against libbar, which doesn't use versioned sonames.
libbar's author changes the number of arguments one of his functions takes.
foo's author is on the ball, and releases a new version that works with the
latest libbar (and can still be compiled with the old version, because foo's
author is a neat freak).
User X has the old versions of foo and libbar installed on his machine, and
hears about a new package, 'baz', which he decides to install.
baz was compiled against the new version of libbar...
How do you construct dependencies here so that neither baz nor foo is broken
for this user?
Steve Langasek
postmodern programmer
(Answer: use sonames...)
Reply to: