Bug#476284: bullet package name/numbering
Hi !
On Sat, Jan 26, 2013 at 4:05 PM, Markus Koschany 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//libbulletcollision.so -> libbulletcollision.so.0
> /usr/lib//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
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#476284: bullet package name/numbering
On Sat, Jan 26, 2013 at 10:05 AM, Markus Koschany 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)
Static is not taboo and can be included in -dev packages. Depending
maintainers, however, are strongly encouraged against using your
static package since it increases the burden of security and
maintenance. I think that you really should include .so to be useful
though.
> 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
> )
>
> 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})
Oh, well that helps - if the soversion is bumped every time then you
might be OK with upstream's build system as is (just enable shared
libraries).
> 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.
FYI: check out OpenMW, they're making good progress and may make it
into Debian in the future.
Although the release team might not like the transitions, I bet they
prefer it to statically linked code throughout the archive. You can
talk with them ahead of time to find ways of responsibly managing
transitions.
> So if i understand the choices correctly, only bumping the SONAME is a
> sane solution.
Yes, if SONAME is bumped with every release, then that is acceptable
and borderline "sane" (sane in that it avoids breakage, however it
also will trigger a large number of transitions). I'm used to projects
that either never set the SONAME or screw up the ABI but not bump
SONAME. This is a different case, where the project is bumping the
SONAME frequently.
> 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
>
> ? In the end the name of the package has to change, correct?
Yes - both would be ok (although the first case might not have the
0.0.0, it would just be libbulletcollision-2.81.so or the package name
would have to be libbulletcollision-2.81-0). That's all I wanted, was
to make sure the package name changes.
To get really confused, see the SDL packages
libsdl1.2debian0 -> libSDL-1.2.so.0.11.4 (Lintian says should be libsdl-1.2-0)
libsdl-1.3-0 -> libSDL-1.3.so.0.0.0
libsdl2-2.0-0 -> libSDL2-2.0.so.0.0.0
> I will also talk to the Multimedia Team who maintains Blender at the
> moment, perhaps they know best what kind of library they need and which
> approach is successful in the end.
Yes, please talk with those that would build with it - their opinions
count a lot
Cheers,
Scott
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#476284: bullet package name/numbering
On Thu, 17. Jan 16:44 Scott Howard wrote:
> If your library belongs to a package that doesn't believe in sane
> SONAME version numbering, but instead releases based on version
> numbers that have nothing to do with binary compatibility, it is
> sometimes best to use the -release LDFLAG:
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
)
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})
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. 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//libbulletcollision.so -> libbulletcollision.so.0
/usr/lib//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.
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
? In the end the name of the package has to change, correct?
I will also talk to the Multimedia Team who maintains Blender at the
moment, perhaps they know best what kind of library they need and which
approach is successful in the end.
Thanks for reading this far
Regards,
Markus
signature.asc
Description: Digital signature
Bug#476284: bullet package name/numbering
On Thu, 17. Jan 16:44 Scott Howard wrote: > Hello, late to the party but wanted to put in a comment regarding > library package naming/versioning. Please ignore this if it has > already been discussed and i missed it in the thread) Hi Scott, you aren't late to the party, it never stops. :) I haven't had the time in the last days to give you a proper answer. Please bear with me for a while, i'll definitely come back to you. Cheers, Markus signature.asc Description: Digital signature
Bug#476284: bullet package name/numbering
Hello, late to the party but wanted to put in a comment regarding library package naming/versioning. Please ignore this if it has already been discussed and i missed it in the thread) If your library belongs to a package that doesn't believe in sane SONAME version numbering, but instead releases based on version numbers that have nothing to do with binary compatibility, it is sometimes best to use the -release LDFLAG: >From the autotools book (but you can adjust it for whatever build system you want) [1] %-snip-% `-release' On occasion, it is desirable to encode the release number of a library into its name. By specifying the release number with this option, libtool will build a library that does this, but will break binary compatibility for each change of the release number. By breaking binary compatibility this way, you negate the possibility of fixing bugs in installed programs by installing an updated shared library. You should probably be using `-version-info' instead. libshell_la_LDFLAGS = -release 27 The above fragment might create a library called `libshell-27.so.0.0.0' for example. %-snip-% So, perhaps, libbulletcollision2.81 should really be: libbulletcollision-2.81.so.0.0.0 and package name "libbulletcollission-2.81" not "libbulletcollision2.81" (note the dash and number is in the name, the version will be appended on to it. This will, however, force everything to be rebuilt whenever upstream releases a new version. [1] http://www.sourceware.org/autobook/autobook/autobook_88.html#SEC88 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
