On Tue, Apr 14, 2009 at 02:27:09PM +0200, Mathieu Malaterre wrote:
> Hi Steve,
>
> I'll be unvailable for the rest of the week. I have been looking at
> was is currently being done in VTK and I see: [...]
Yes, both are using the same convention; i.e. the SOVERSION is
"Major.Minor".
> AFAIK the vtk package is named libvtk5.
Yes, but it shouldn't be; c.f. Bug #520906 [1] and Debian
Policy section 8.1 [2]:
The run-time shared library needs to be placed in a package whose
name changes whenever the shared object version changes. The most
common mechanism is to place it in a package called
librarynamesoversion, where soversion is the version number in the
soname of the shared library. Alternatively, if it would be
confusing to directly append soversion to libraryname
(e.g. because libraryname itself ends in a number), you may use
libraryname-soversion and libraryname-soversion-dev instead.
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=520906
[2] http://www.debian.org/doc/debian-policy/ch-sharedlibs.html
> I'd like to follow the same convention as VTK (preserve API compat
> in every minor version bump up). Do you think this is reasonable ?
The SOVERSION, however, has nothing to do with API. It is a marker of
ABI -- whether the shared object is *BINARY* compatible or not. The
versioning chosen by VTK and GDCM promises binary compatibility only
across patch-level revisions -- i.e. the third dot of the M.m.p
version string. Versions M.m.0 and M.(m+1).0, on the other hand,
are presumed to be ABI-incompatible.
That's fine; as upstream author, you may decide what to promise.
Based on this, however, Debian Policy dictates what the debian package
name must be.
Regards,
-Steve
Attachment:
signature.asc
Description: Digital signature