Re: upstream library without a SONAME
Hi Steve,
On Wed, 25 Jul 2001, Steve M. Robbins wrote:
> > > I thought a "SONAME" was something embedded into the shared object
> > > file. As I understand things, the SONAME is completely independent of
> > > the file name, at least in principle.
> > It's not quite that simple.
> > There's a good description of things included in the libtool documentation.
> > Install libtool-doc and read the texinfo section on versioning.
> That is a nice, rational versioning scheme, I agree.
> I don't see how it fits in this discussion, though. For one thing,
> I'm not using libtool. More importantly, all libtool does is manage
> the choice of SONAME for you. At the end of the day, there is still a
> single SONAME embedded in your shared library.
> 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. This is the only
way to cleanly manage upgrades involving binary-incompatible versions of a
library. If we cannot identify the ABI from the package name, we cannot
generate proper dependency information. If the ABI is not uniquely reflected
by an SONAME in the library itself, it cannot be registered correctly with
ldconfig, and therefore each incompatible version of this library must
conflict: with all the others because they cannot coexist on the system
without causing serious breakage of other packages.
If you can come up with another approach which will not cause RC bugs, you are
welcome to use it, but I can't think of anything less-complicated than SONAMEs
which will allow this.
> 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.
Steve Langasek
postmodern programmer
Reply to: