Bug#123887: [Evms-devel] EVMS: shared libraries with unversioned sonames
On Wednesday 02 January 2002 14:04, Adam Heath wrote:
> On Wed, 2 Jan 2002, Kevin Corry wrote:
> > What if we used libevms.so.x as the soname, and libevms-x.y.z.so as the
> > filename for the library (where x is the version major number, y is
> > minor, and z is patchlevel)? This seems to be common on many of the
> > libraries on my system.
> >
> > Basically, we don't want to force the user-interfaces to to be
> > recompiled on every minor change to the engine core that doesn't change
> > any of the external APIs. We only intend to change these APIs across a
> > major version change. At most, new APIs may be added, but existing ones
> > (and their defined functionality) will remain the same. Having the soname
> > include only the major number means the existing binary user-interfaces
> > could be used if a new minor or patch-level version of the engine library
> > appears.
>
> So, when you need to make an incompatible change, what would you do? There
> is no version in the SONAME, so you are SOL(shit, out of luck).
>
> The SONAME *MUST* has a version encoded into it. Otherwise, I would rather
> see this library NOT included in debian, no matter how good it is, or what
> it does.
Um, I just suggested using libevms.so.x as the soname. x is the major version
of the library, so the SONAME has a version number encoded in it. My question
was simply, how detailed a version number does it need to be. Is the major
number sufficient, or does it need to be major.minor.patchlevel?
If an incompatible API change needs to be made, the major number will be
incremented, and thus the existing binaries will need to be recompiled.
As I said, many other existing libraries on my system use just the major
version in their SONAMEs (e.g. libc.so.6, libdl.so.2, etc), so it seems that
this method should be sufficient.
-Kevin
Reply to: