Unbundling Bullet

[limburgher]

Hi, Jon Ciesla, vdrift RPM maintainer for Fedora.

Thomas Spura has created a patch against vdrift 2010-06-30 that allows building it with a system version of Bullet(2.77 in this case), rather than having to use an older bundled version. This will help with security updates, and also allows it to be in compliance with Fedora's bundled library restriction, which other distros may also do, I'm not sure. It would make things easier for us at Fedora, and probably for you as well, if you incorporated this patch into your codebase. Assuming that you're interested, to whom should I send the patch for consideration?

Thanks,

Jon

[NaN]

Hi Jon, can you point me towards this patch?

[fudje]

Source tree bundling is the preferred use case for Bullet. That way the project can target a specific ABI without problems.

See:
http://bulletphysics.org/Bullet/phpBB3/v...613#p20613
http://www.bulletphysics.org/Bullet/phpB...120#p11120

And probably other places too.

There should be no reason for Fedora to even package bullet in the first place....

[limburgher]

Index: include/cardynamics.h
===================================================================
--- include/cardynamics.h
+++ include/cardynamics.h 2011-02-19 15:58:42.924055598 +0100
@@ -20,6 +20,7 @@
#include "collision_contact.h"
#include "cartelemetry.h"
#include "BulletDynamics/Dynamics/btActionInterface.h"
+#include "BulletDynamics/Dynamics/btRigidBody.h"

class MODEL;
class CONFIGFILE;
--- src/SConscript.orig 2011-02-19 17:32:57.927061608 +0100
+++ src/SConscript 2011-02-19 17:33:41.211055956 +0100
@@ -233,7 +233,7 @@
#--------------------------#
appdir = ""
vdrift_install = None
-common_libs = ['SDL_image', 'SDL_gfx', 'vorbisfile', 'vdriftbullet']
+common_libs = ['SDL_image', 'SDL_gfx', 'vorbisfile']

if (sys.platform == 'freebsd6') or (sys.platform == 'freebsd7') or (sys.platform == 'freebsd8'):
common_libs.append('libbulletcollision')
@@ -305,9 +305,8 @@
# Compile Executable #
#--------------------#
#vdrift = local_env.Program(target='%s${EXECUTABLE_NAME}' % appdir, source=[src, vamosobjs, guiobjs])
-vdriftbullet = local_env.Library('vdriftbullet', bullet_src);
+local_env.ParseConfig('pkg-config bullet --libs --cflags')
vdrift = local_env.Program(target='%s${EXECUTABLE_NAME}' % appdir, source=src)
-Depends(vdrift, vdriftbullet)
Default(Alias('vdrift', vdrift))

#---------#

[limburgher]

I can also email it to whomever.

fudje, I understand that upstream wants bullet to be bundled, but the Fedora Packaging Guidelines forbit it except in exceptional cases, primarily for security reasons. It's easier to patch a library once than it is to try to figure out which 50 packages may or may not be affected because we think they might be bundling a given library, and they're all using different versions. We do grant exceptions in some cases, for example, where there are significant modifications to the bundled library that the library's upstream won't adopt, or if the application will only work with an old version and can't be ported to the new version.

[joevenzon]

Originally we *didn't* use a bundled version, and it caused problems due to ABI issues; maybe that isn't the case anymore, and we can try it out again, but if you want to distribute bullet system-wide, you should really be urging the bullet physics developers to start supporting system-wide installation.

[alex25]

for all its worth, i've been compiling vdrift against bullet from svn from the very beginning and i never had any problems.

--alex--

[fudje]

I've read the Fedora Packaging Guidelines with respect to bundling, and in general conditions it does make sense, and the concerns are valid.

However, Bullet is designed with bundling specifically in mind, and it is not made with packaging more than barely considered. A fair number of binary games distribute with it, and you wouldn't even know if you don't look at symbol tables. It's not only ABI that's the issue either – there's no guarantee that the same apparent data input will give the same results across different versions.
I'm curious how this is handled by Blender, since they bundle it too.

Anyway, if you really must use a system version of bullet, applying your patch during package build is probably the best solution. Removing the bundling from the source package is unsavoury (and probably unworkable), and even adding a switch to "enable system bullet (not recommended)" will cause people to try it anyway and complain when it doesn't work well for them.

[NaN]

Removing the bundling from the source package is unsavoury (and probably unworkable), and even adding a switch to "enable system bullet (not recommended)"

All we need is a way to link against a specific system bullet version. Something like libbullet277. Are distributions supporting multiple bullet versions?

[limburgher]

Removing the bundling from the source package is unsavoury (and probably unworkable), and even adding a switch to "enable system bullet (not recommended)"

All we need is a way to link against a specific system bullet version. Something like libbullet277. Are distributions supporting multiple bullet versions?

I can't speak for other distributions, but Fedora isn't. If you don't want to implement our patch, that's really your choice, but we'll be using it either way. We just thought it might be of value to you.

[NaN]

It's not about wanting or not. It is about trying to understand the implications.

How do you deal with this as maintainer:
http://code.google.com/p/bullet/source/detail?r=2078
http://code.google.com/p/bullet/source/detail?r=2154

We are not affected by this fixes as we are only using a small subset of bullet. But they might cause deviation in simulation behavior between 2.77 and 2.76.

[limburgher]

It's not about wanting or not. It is about trying to understand the implications.

How do you deal with this as maintainer:
http://code.google.com/p/bullet/source/detail?r=2078
http://code.google.com/p/bullet/source/detail?r=2154

We are not affected by this fixes as we are only using a small subset of bullet. But they might cause deviation in simulation behavior between 2.77 and 2.76.

I would imagine that fixes in portions of Bullet you're not using wouldn't affect your code. If they do, it would be reported as bug by a user, and triaged appropriately. If the modifications to the bundled bullet are significant enough and incompatible with upstream bullet in a way that effects the functioniality of vdrift, it would likely be granted a bundling exception my the Fedora Packaging Committee, but we try to avoid that if possible.

[NaN]

Support for linking against system bullet is in trunk, although not officially supported.

[limburgher]

Support for linking against system bullet is in trunk, although not officially supported.

So we're likely to see it in the next release?

[NaN]

I think we could default to it. The problem is to guarantee that it will work with the available system bullet versions out there without simulation bugs. I do not plan to do any regression testing against different bullet versions.