Re: [med-svn] r3263 - trunk/packages/gdcm/trunk/debian

[Mathieu Malaterre <mathieu.malaterre@gmail.com>]

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:

IF(NOT VTK_NO_LIBRARY_VERSION)
  SET(VTK_LIBRARY_PROPERTIES ${VTK_LIBRARY_PROPERTIES}
    VERSION "${VTK_VERSION}"
    SOVERSION "${VTK_MAJOR_VERSION}.${VTK_MINOR_VERSION}"
    )
ENDIF(NOT VTK_NO_LIBRARY_VERSION)

while in GDCM:

SET(GDCM_LIBRARY_PROPERTIES ${GDCM_LIBRARY_PROPERTIES}
  VERSION "${GDCM_VERSION}"
  SOVERSION "${GDCM_MAJOR_VERSION}.${GDCM_MINOR_VERSION}"
)


AFAIK the vtk package is named libvtk5. 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 ?

In which case the next gdcm version will not be gdcm 2.0.11 but a gdcm
2.2.0, this will clearly warn user of a potential ABI changes (I
garantee API compat).

Thanks again for your time,


On Fri, Apr 10, 2009 at 9:26 PM, Steve M. Robbins <steve@sumost.ca> wrote:
> Hello Mathieu,
>
> On Fri, Apr 10, 2009 at 10:02:19AM +0200, Mathieu Malaterre wrote:
>
>> > Looking more closely now at the rest of the shared libs, I see that
>> > most of the libgdcm*.so* libraries have SOVERSION "2.0". ?A shared lib
>> > package needs to have the SOVERSION in its name, so the package should
>> > be renamed libgdcm2 --> libgdcm2.0. ?Similarly, libvtkgdcm -->
>> > libvtkgdcm2.0.
>>
>> Writing the initial debian packaging I was suggest a package which
>> followed this very same convention. For instance on my system I have a
>> libopenjpeg-dev which pulls in a libopenjpeg2 package when installed.
>
> OK, pardon me for belabouring the point, but I want to be clear on
> this.  The debian packaging has to allow different versions of the
> shared object (i.e. different SOVERSIONs) to coexist.  This is
> accomplished by having the SOVERSION encoded in the package name.
> Many (probably most) shared libs simply encode the library's major
> version in the SOVERSION, so you do end up with libopenjpeg2.  Some,
> like GDCM, encode major.minor in the SOVERSION, so you need to name
> the package correspondingly.  This is why it should be libgdcm2.0.
>
>
>> At some point I even looked at libtiff / libpng which lead me to the
>> conclusion that package numbering was to indicate major version (ie
>> API change).
>
> The SOVERSION tracks *ABI* change, not API; but yes, the package
> numbering is to track ABI change.
>
> If you, as the upstream author, guarantee ABI stability across minor
> revisions of the same major version, then you can change the
> CMakeLists to encode only the major version in the SOVERSION (and then
> the package name would indeed be libgdcm2).
>
>
> Regards,
> -Steve
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iD8DBQFJ351K0i2bPSHbMcURAjA5AKCDErXfMSBhbzMvDk4jIlBBrz+hEACeLfs/
> 0xK7jg2TKfx/ainlUpzLIf8=
> =dHMC
> -----END PGP SIGNATURE-----
>
>



-- 
Mathieu