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