Re: ITK debian packages
Hi Steve,
On Mon, Feb 27, 2006 at 12:16:05AM -0500, Steve M. Robbins wrote:
> Now that I have gccxml and cableswig built (locally), I'm having
> a closer look at the ITK packages themselves.
>
> You've patched several CMakeLists.txt files to set the VERSION and
> SOVERSION of shared libraries.
Yes, there's a few patches like that which I was holding off sending
upstream until it becomes "official", and there are others (such as fixing
the installation into the InsightToolkit subdirectory of /usr/lib) which
violate Debian policy that I would simply maintain.
> Did the suggestion of SOVERSION of 4 come from upstream? Are they
> going to incorporate this?
>
> Why is VERSION set to "2.4.0"? Shouldn't it normally start with the
> same number as SOVERSION?
No, upstream haven't been using SOVERSION, it is just the packages I built
for Debian that use them. I don't imagine they would be adverse to putting
the change in the upstream sources, but the problem would arise whereby
essentially every single release would break ABI (thanks to C++) and thus
require a new SOVERSION, which they would have to maintain. It seemed
simpler, at least in the beginning, to manage this in the package itself.
Although now ITK seems to be on a 6-monthly release cycle, this may not be
such an issue.
The idea was to make the VERSION the same as the official ITK release
version, and the SOVERSION (which I understand should be a single
monotonically increasing number) would increment each time. This is just
the 4th release of the debs.
> For reference, VTK 5 builds using
>
> SET(VTK_MAJOR_VERSION 5)
> SET(VTK_MINOR_VERSION 0)
> SET(VTK_BUILD_VERSION 0)
> SET(VTK_VERSION
> "${VTK_MAJOR_VERSION}.${VTK_MINOR_VERSION}.${VTK_BUILD_VERSION}")
>
> SET(VTK_LIBRARY_PROPERTIES ${VTK_LIBRARY_PROPERTIES}
> VERSION "${VTK_VERSION}"
> SOVERSION "${VTK_MAJOR_VERSION}.${VTK_MINOR_VERSION}")
As I understand it, that doesn't conform to policy, since the SOVERSION is
has more than one component. Wouldn't that lead to something like this?
libVTKCommon.so -> libVTKCommon.so.5.0 -> libVTKCommon.so.5.0.0
| /
SONAME=libVTKCommon.so.5.0
I thought it was supposed to be more like this, to pick simple but real
example:
libz.so -> libz.so.1 // default lib is linked to soversion=1
libz.so.1 -> libz.so.1.2.3 // soversion=1 links to the real lib
libz.so.1.2.3 // the real library with full version
And looking at the way it is linked:
% objdump -p /usr/lib/libz.so | grep SONAME
SONAME libz.so.1
where 1 is the SONAME version, and libz is the package name. (Then again,
I'm surprised/impressed since that would imply libz has never broken binary
compatability?!)
So for the ITK releases I did, it was something like this (from memory):
Version soversion
1.6 1
1.8 2
2.0 3
2.4 4
Does that make sense? I could have missed something, so please correct me
if I am mistaken. I tried to ensure the the ITK packages and their
versioning conformed to policy, but it's such a complex and misunderstood
topic. I have tried to follow Junichi's guide:
http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html
> Maybe we could suggest/request that upstream adopt something similar?
Sure, I imagine they would be happy to make this a more official change,
once we sort out a consistent scheme.
:: Gavin
--
Gavin Baker Complex Systems Group
http://www.cs.mu.oz.au/~gavinb The University of Melbourne
Reply to: