Bug#476284: bullet package name/numbering

[Vincent Fourmond <fourmond@debian.org>]

  Hi !

On Sat, Jan 26, 2013 at 4:05 PM, Markus Koschany <apo@gambaru.de> wrote:
> Hi Scott and Vincent,
>
> thank you for your feedback. At the moment i see two alternatives
> (three if a static library is not a taboo)
>
> I'm using CMAKE as build system because it is better supported by
> upstream. I can achieve something similar to the autotools -release
> LDFLAG with
>
> SET_TARGET_PROPERTIES(
>         BulletCollision
>         PROPERTIES
>                 VERSION 2
>                 SOVERSION 2.8.1
> )

  As far as I understand cmake's docs on that (or, rather, the bits I
found on mailing lists),  this makes a SONAME of 2.8.1, which still
means a SONAME bump for every version change.
>
> although you can find the following lines in upstream's CMakelists.txt
> files:
>
> SET_TARGET_PROPERTIES(BulletCollision PROPERTIES VERSION ${BULLET_VERSION})
> SET_TARGET_PROPERTIES(BulletCollision PROPERTIES SOVERSION ${BULLET_VERSION})

  I don't think this makes any difference with what you came around
with. The ideal would be to have SOVERSION be a plain integer that
increases by one every time the ABI is broken. But, this is not a
sustainable approach so long as upstream isn't into it.

> So apparently upstream intends to use the release version as SONAME for
> the library. The background to this is, Bullet is a physics library.
> Every new release the physics can slightly change which can result in
> unexpected ingame behaviour of certain objects thus games are normally
> tuned for a specific bullet release.

  If that is really that bad, it is really painful, as you will not be
able to maintain all the versions of the library that are needed for
every specific depending package in the archive. Making a static
library won't help here, as a simple binNMU would make significant
changes to an otherwise OK package.

> Perhaps this might be different in
> the case of Blender or Panda3D (not yet packaged).
>
> With the above CMAKE construct i can produce libraries like
>
> /usr/lib/<Triplet>/libbulletcollision.so -> libbulletcollision.so.0
> /usr/lib/<Triplet>/libbulletcollision.so.2 -> libbulletcollision.so.2.8.1
>
> but i have to patch all CMakelists.txt files. (I don't know if there is an
> easier solution within debian/rules.)
>
> So in theory it is possible to create a sane versioning scheme but this
> is completely unsupported by upstream and will most likely result in
> broken games because we cannot assess what effects a new version of
> Bullet will have on ingame physics.
>
> As Vincent has already said, the Release Team won't like the thought to
> make a transition every time a new Bullet version is released. But is
> this really so bad? I mean, there are only a few packages which would
> depend on Bullet like Blender, perhaps Supertuxkart and probably
> FreeOrion.

  For the time being, I suggest you stick to upstream way of doing
things regarding SONAME, and that when you're fed up bothering the
release team for transitions, you'll have the energy and the
background necessary to talk upstream into making something more
stable ;-)...

  I would not recommend making it a static library. Linking with
static libraries has many drawbacks (in terms of security) and should
be avoided as much as possible.

> So if i understand the choices correctly, only bumping the SONAME is a
> sane solution.
>
> Provided the aforementioned assumption is true, is there really a difference
> between
>
> libbulletcollision-2.81 -> libbulletcollision-2.81.so.0.0.0
>
> libbulletcollision2.81 -> libbulletcollision.so.2.81
e
>
> ? In the end the name of the package has to change, correct?

  I'm not sure I see what you mean here. I'm not sure you can have
such thing as a library named libbulletcollision.so.2.81, but my
knowledge of ld.so and friends clearly has its limits ;-).

  Hope all this helps,

  Cheers,

      Vincent