For the Debian-devel folks just tuning in: we're debating how to
introduce a SOVERSION to the ITK libraries that lack it upstream. The
current thread starts at
http://lists.debian.org/debian-med/2006/02/msg00037.html
Your input is welcomed.
On Thu, Mar 02, 2006 at 03:23:47PM +1100, Gavin Baker wrote:
> > 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.
You really, really want upstream in charge of versioning the library.
If they can't guarantee any compatibility across releases, then the
SOVERSION should change on each release. It's as simple as that.
Boost, for example, takes this approach. The SOVERSION contains
the complete version number:
objdump -p libboost_filesystem.so |grep SONAME
SONAME libboost_filesystem-gcc-mt-1_33_1.so.1.33.1
> 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.
That's a common convention but not mandatory, as I understand it.
Looking through my /usr/lib I can find several counterexamples. Here
are SONAMES of a few:
libapt-inst-libc6.3-6.so.1.1
libbz2.so.1.0
libcrypto.so.0.9.8
libestbase.so.1.2
> > 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.
I can't find anything in Debian Policy that discusses the form that
SOVERSION must take. I do see section 8.1 that discusses the
*package* name derived from SONAME. What policy section are you
worried about?
> Wouldn't that lead to something like this?
>
> libVTKCommon.so -> libVTKCommon.so.5.0 -> libVTKCommon.so.5.0.0
> | /
> SONAME=libVTKCommon.so.5.0
Yes, I believe so.
> 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?
You really, really want upstream in charge of versioning. Suppose, for
example, they published ITK version 3.0 with soversion 3. Then what?
> 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
That's a helpful starting point. But even there I don't find any hint
that Debian Policy mandates a particular style of SONAME versioning.
[Which is a good thing, actually, since opinions differ and we cannot
really bend all of upstream library authors to our will.]
> > 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.
My hunch is that ITK authors will be amenable to using the same scheme
as VTK since the two upstreams overlap a lot. So I would propose to
them the same as the newer VTK, i.e
SOVERSION = "${ITK_MAJOR_VERSION}.${ITK_MINOR_VERSION}"
But mainly I propse to raise the issue on the ITK developer list
and debate it there.
Regards,
-Steve
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
