This is because of the following policy.

https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries

If you need patches applied, you are more than welcome to file BZs for the relevant Fedora components and ask that they be applied.

As an enduser, and original reporter in STK's github, I have also raised a BZ 
https://bugzilla.redhat.com/show_bug.cgi?id=1146456, with my webcast

Sorry, I don't understand this. We give you a patch, which changes your system bullet - so all other application that uses your system bullet won't work as expected anymore? <sarcasm>Do you care if applications you package actually work as expected, or is it enough if you just have a long list of potentially broken applications? </sarcasm> Sorry, couldn't help it ;)

As I've said, we had that discussion before, on
http://forum.freegamedev.net/viewtopic.php?f=17&t=3906&p=39632&hilit=bullet#p39603
I list some of the changes we had to apply to bullet. And yes, disabling SSE will affect other applications that need the potential speed boost SSE gives - in our case, some code in STK triggers exceptions in an unmodified bullet since some memory is not properly aligned for SSE. And no, it does not happen all the time or is easily reproducible.

I also just realised that you additionally replaced our irrlicht version. This is even worse, in our irrlicht version we had to change a hard coded maximum number of textures (which the irrlicht developer did not want to apply since they were afraid of backwards compatibility, performance etc - see http://irrlicht.sourceforge.net/forum/viewtopic.php?f=2&t=49294&p=284232#p284159). To quote the irrlicht developer: "And that Linux distributions make it so hard for application developers to work with modified library code is unfortunate and imho completely against the spirit of free software."  So they are certainly in favour of us including our own irrlicht version.

Using an unmodified irrlicht with stk has caused bugs in the past (unless you modified your system irrlicht version, in which case as the above irrlicht shows further on the performance will be impacted for other applications. We made sure that it is fine for STK, did you do those tests?). We got many many bug reports from stk using a certain distribution (which used a system irrlicht), and all were fixed once those people used our binaries (see e.g. https://bugs.launchpad.net/ubuntu/+source/supertuxkart/+bug/1064019). <sarcasm>Is that the goal of your policy?</sarcasm>

Our included libraries are patched, and _tested_. We only include libraries that need patches in order for STK to work as expected. In all cases the changes either won't apply to other applications (e.g. our bullet changes which are specific to supertuxkart), or have been reported upstream and were rejected. Updating the bullet version already required you to make changes, just in order to compile (I checked, bullet 2.82 still declares some member variables private, which we need to be protected). Did you test if any other changes affects the kart physics? Those can be subtle changes, e.g. a kart just not touching the ground in some situation, meaning people are not able to steer when they need to - which result in them thinking that our game is just bad. The bullet developer states that the API, and physics behaviour can change from one version to the next (e.g. search for COMPATIBLE_0_7_3 in stk/src/physics/btKart.cpp, where 2.79 was broken for us compared with 2.73 and we had to patch it - luckily we could do this locally).

Our version of STK is tested to make sure the graphics and physics behave as expected. Your version causes bugs, e.g. https://bugzilla.redhat.com/show_bug.cgi?id=1146456 . If you don't use our libraries, then please fix this bug.

And also: if you don't use our version of the libraries, what options do we have to remove SuperTuxKart from Fedora? Our development team is quite upset at being pointed to a policy which results in our game being broken, and affecting the public perception of SuperTuxKart, and in turn perhaps even the state of open source games in general. It's also very annoying for me to have to fight to get a working game into distributions - we do try our best to support packager as far as possible, but all we get back in return is a broken game for our users :(

Thanks a lot!
  Joerg aka hiker

The policy page you were linked to has a rather long and detailed explanation of the procedure for requesting exceptions. There's no need for anyone to get angry about anything here, we have a policy for a good reason, and the policy has a reasonable procedure for exceptions. Just go ahead and follow that procedure.

Hi,

I've applied for a bundled library exception at https://fedorahosted.org/fpc/ticket/459

Bye
  Joerg

I just wonder why this practice is necessary since it should obviously be packager responsibility that the programs they package work in the intended manner within the distribution. Us getting involved and having to do this should not have to happen.

First, my apologies for not providing a more nuanced reply, my life has been somewhat full as of late and there's a lot there to reply to.

First, patches to bullet and irrlicht should be submitted to those components either upstream, or if they won't take them, the relevant components in Fedora, as I said in Comment 1.  I don't see that that's been done, at least within Fedora.

Second, to respond to the quoted statement from the irrlicht team, modifying code is absolutely not against the spirit of free software, it is actually part of the point.  https://www.gnu.org/philosophy/free-sw.html

Third, I cannot reproduce any of the bugs you claim our unbundling introduces, that you say yourself are hard to reproduce.  Hence my somewhat reduced sense of urgency.

Fourth, and this is simple curiosity, not a request for action, why can the functionality you require in STK not simply be implemented in STK rather than bundling and modifying the libraries you need?  By bundling, you're committing to releasing a new patched version (with patches you have to come up with, test, etc) every time there's a security flaw in bullet or irrlicht.  I've not seen STK release that frequently, so I'm unsure that that's occurred or occurring.  If it is, that's good.

And to clarify, we're unable to distribute prebuilt binaries for a number of reasons.

https://fedoraproject.org/wiki/Packaging:Guidelines#No_inclusion_of_pre-built_binaries_or_libraries

Hi,

thanks for your answer. I inline my answer (I hope the > work as expected):

> First, my apologies for not providing a more nuanced reply, my life has been
> somewhat full as of late and there's a lot there to reply to.
Sure, no problem - we all have a real life ;)

> First, patches to bullet and irrlicht should be submitted to those components 
> either upstream, or if they won't take them, the relevant components in 
> Fedora, as I said in Comment 1.  I don't see that that's been done, at least 
> within Fedora.
Where reasonable we tried: Irrlicht rejected our changes (since they would cause a slow down for other applications). Our changes to bullet are STK specific: we tweaked the physics to get the right feeling. Those changes are quite 'unphysical' (e.g. introducing artificial forces to keep the kart on ground), since we aim for an arcade feel, not a realistic car racing simulation. So applying our changes might in bullet might break other applications that use bullet.

I have no idea how to submit the changes directly with Fedora, and I don't want to deal with that tbh (there are dozens of distros out there, we don't have the man power to deal with all of them, imho that should be the packager's task).

Furthermore, I am not even sure you would want to bundle our changes - as the irrlicht developers have said, our change causes a slowdown of other applications, so you would affect other applications that uses irrlicht (and if there are no other applications that use irrlicht/bullet - then why are we having this discussion in the first place - both libs are statically linked in, no need to install them at all).


> Second, to respond to the quoted statement from the irrlicht team, modifying 
> code is absolutely not against the spirit of free software, it is actually 
> part of the point.  https://www.gnu.org/philosophy/free-sw.html
You might have misread that statement. They wrote: "And that Linux distributions make it so hard for application developers to work with modified library code is unfortunate and imho completely against the spirit of free software." So, it's not irrlicht that makes it hard to modify open source code (they actually encouraged us to do so when they rejected our patches).


> Third, I cannot reproduce any of the bugs you claim our unbundling 
> introduces, that you say yourself are hard to reproduce.  Hence my somewhat 
> reduced sense of urgency.
The changes we have done are mostly indeed subtle (e.g. we noticed that sometimes people could not control a kart in certain situations). Unless you know how STK is supposed to feel, and do a _lot_ of testing, those changes will not be obvious, short of players complaining about the physics not feeling right, not being able to control the kart etc. We try to give our users a very good experience, and we take a certain pride in the amount of detail that we spent in those things.

But the main issue is not that your unbundling causes those minor effects, the main issue is that your unbundling and upgrading completely breaks game play. One of our team installed Fedora, and apparently you can play football with the bowling balls ;)  I.e. you can push them around ... while karts are supposed to explode (and then the balls should disappear). Same effect in the video, where the basketball does not affect the kart at all. The ball should explode, throwing the kart up in the air. This should be easy enough to reproduce. Also, apparently a warning is printed that irrlicht was compiled in debug mode, i.e. without optimisations is printed, which can have severe impact on frame rate and playability of the game.

This is not a minor change, your bundle is nearly completely broken. While it is admittedly possible that we have bugs, we have never heard of a bug like the ones reported for the Fedora package, and testing showed that on Fedora the bug happens with the STK packages, but not with our binary. If it should be something else (e.g. compiler bug, ...), we can certainly try to help you finding the reason, but as long as you use the wrong bullet version there's nothing we can do :(  It is known that bullet changes physics, api, ... from version to version, and that for this reason they recommend to include bullet in your project (imho you should have a general permission for bullet to be bundled, there are too many things that can break - for example, we had problems in the past that using SSE would crash since apparently some memory is not aligned properly).

But even if the broken gameplay would be fixed, all our work in fine tuning the physics could potentially still be broken by using a standard bullet version. I already receive complains from our artists and developers, who see it that distros are destroying their work, and want to know if we can prevent distros from bundling STK in the first place. A small example: some people might want to use STK when applying for jobs. If any potential employer should download and play the Fedora version, what do you think will be the chances to get a job? I don't want to do this, so I hope we can work together to sort this out.

A first point: would it be possible for packagers to actually contact the developers before changing included libraries etc? We will be adding checks in our build procedure and in stk at runtime to detect if wrong versions of libraries are being used, so packager will notice this. But we certainly would prefer discussing your concerns with you in the first place (as other packagers have done, before agreeing with out reasons), instead of having to write code to detect if someone fiddles with the build environment ;)

> Fourth, and this is simple curiosity, not a request for action, why can the 
> functionality you require in STK not simply be implemented in STK rather than 
> bundling and modifying the libraries you need?  By bundling, you're 
> committing to releasing a new patched version (with patches you have to come 
> up with, test, etc) every time there's a security flaw in bullet or 
> irrlicht.  I've not seen STK release that frequently, so I'm unsure that 
> that's occurred or occurring.  If it is, that's good.
For bullet, we tried to do this partly, but some of the class interfaces were not designed for that, so we fixed the declaration in bullet, and then derived our own classes where many (if not most) of the changes are. I am actually wondering how you could even compile STK with bullet 2.82 without patching those function/member declarations. From what I have seen no change to make the methods and members accessible was applied to bullet 2.82 in Fedora, and you should have received some compiler errors about private members not accessible. I also checked bullet 2.82 from upstream, and those changes have not been applied yet.

As stated before, the irrlicht developer rejected our changes. It will be even worse in our next release, we did a lot more changes to irrlicht, which will break any compatibility completely.

For us your policy is basically forcing us to fork all those libraries, to avoid those mess up later. I don't particularly like this, since I want to give credits where credit is due, and people should know and see that stk is based on irrlicht and bullet. But we are now considering using supertuxkart_arrow and supertuxkart_normal_darkness instead of bullet and irrlicht.

Re patches and security fixes: we will fix whatever needs to be fixed, though we do encourage packagers to use system libpng/jpeg (for which there is a configuration option). All our assets are of course tested, and assets from our addon servers are re-packaged (i.e. unzipped and zipped again), to detect at least most issues.


> And to clarify, we're unable to distribute prebuilt binaries for a number of
>  reasons.
Oh, of course I never intended you to distribute our binaries ;)

supertuxkart-0.8.1-9.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/supertuxkart-0.8.1-9.fc20

supertuxkart-0.8.1-9.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/supertuxkart-0.8.1-9.fc21

Package supertuxkart-0.8.1-9.fc21:
* should fix your issue,
* was pushed to the Fedora 21 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing supertuxkart-0.8.1-9.fc21'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-12933/supertuxkart-0.8.1-9.fc21
then log in and leave karma (feedback).

supertuxkart-0.8.1-9.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

supertuxkart-0.8.1-9.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.