How I built SuperTuxKart with system libraries only

How I built SuperTuxKart with system libraries only

Postby Gallaecio » 11 Dec 2012, 20:57

I just needed to share this beyond a post on Identi.ca.

SuperTuxKart (STK) provides its own copies of Bullet, Enet, Irrlicht and WiiUse. My guess is that they distribute them because of distributions that do not have the right versions of those. Now, I’m a packager of a (half-)rolling distro, which means the packages here are pretty up-to-date, and the system Bullet, Enet, Irrlicht and WiiUse should be new enough for STK.

So I just patched the CMakeLists.txt file to use the system libraries instead. CMake has built-in support for Bullet, but not the rest as far as I know, so I searched for existing CMake modules for the other three libraries in other FOSS projects, and found them: FindEnet.cmake, FindIrrlicht.cmake and FindWiiUse.cmake. So I put them in the cmake folder of STK, and modified the main CMakeLists.txt file as shown in the patch above.

Other than that, I just needed to modify an #include for the WiiUse header file. A sed command was enough, though:

Code: Select all
sed -e "s#wiiuse/wiiuse.h#wiiuse.h#" -i src/input/wiimote_manager.cpp


And that’s how you build STK with system libraries only :)
Gallaecio
 
Posts: 62
Joined: 14 Jan 2010, 20:23

Re: How I built SuperTuxKart with system libraries only

Postby Hero » 11 Dec 2012, 21:00

Maybe you could sign up on the supertuxkart.sourceforge.net wiki to post about this sort of thing. Not everyone visits the forums.
Keep your mouth closed while chewing your food! That's ALL I hear.

For more game forums go to opengameforums.zxq.net and register today!
User avatar
Hero
 
Posts: 614
Joined: 13 Oct 2012, 21:27
Location: British Columbia, Canada

Re: How I built SuperTuxKart with system libraries only

Postby Arthur » 11 Dec 2012, 21:41

We use a patched version of Irrlicht. Please be adviced that not using the libraries we supply may break things in the game, and any bugs reported might be questioned due to the aforementioned.
Hey pal, I took an oath for justice! "In happy days or tightest tights..." or something like that.
__________________________________________________________________________
Image
User avatar
Arthur
 
Posts: 877
Joined: 06 Dec 2009, 00:49

Re: How I built SuperTuxKart with system libraries only

Postby hiker » 11 Dec 2012, 23:20

Gallaecio wrote:SuperTuxKart (STK) provides its own copies of Bullet, Enet, Irrlicht and WiiUse. My guess is that they distribute them because of distributions that do not have the right versions of those.

No. The reason is that this is recommended by the developers, because
  • they often break the API from one version to the next (bullet), and atm for example we do not even use (nor support) the latest bullet version.
  • we apply bug fixes. Those are reported back to the developers, but might not be fixed before the next release of the corresponding library, which is too late for us (e.g. we only recently fixed a memory leak in bullet). Using a standard bullet will result in memory leaked constantly in each race.
  • we need changes to compile-time constants (irrlicht), which the developers are not willing to make in their source code (and they recommended to use our own version)

So please, do not go this way, you will create a buggy version of STK, which will make players unhappy with STK, and causes us problems by people reporting the bugs you have (re-)introduced. If you do not want to support our included library, then please do not include STK, since your version will be buggy. Instead ask your users to download our linux binaries.

Cheers,
Joerg
Image
hiker
STK Moderator
 
Posts: 1300
Joined: 07 Dec 2009, 12:15
Location: Melbourne, Australia

Re: How I built SuperTuxKart with system libraries only

Postby hasufell » 12 Dec 2012, 21:52

hiker wrote:[*]they often break the API from one version to the next (bullet), and atm for example we do not even use (nor support) the latest bullet version.

That's not an argument at all. Distros have means to handle API breakage of libraries. (soname, any1?)
That should not be your concern at all and you can blame distributors to fix this.
hiker wrote:[*]we apply bug fixes. Those are reported back to the developers, but might not be fixed before the next release of the corresponding library, which is too late for us (e.g. we only recently fixed a memory leak in bullet). Using a standard bullet will result in memory leaked constantly in each race.

That's understandable, somehow. However you should document that in the tarball (in README or INSTALL file) with a reference to the upstream bug report, so that packagers can be aware of the situation and unbundle it if your patches made it upstream.

This should always be considered an unresolved bug.
hiker wrote:[*]we need changes to compile-time constants (irrlicht), which the developers are not willing to make in their source code (and they recommended to use our own version)[/list]

That's the only real problem so far. There are solutions, but I can understand that these might not be viable:
1. fork it
2. switch to a different library (is there even one?)

I know that these suggestions might be completely unrealistic.


Let me just sum up why bundling is bad and should be avoided if possible. I don't expect you to do something about it right now, but I hope that you still consider this situation a "bug":
  • security: bundled libraries are somehow out of the scope of packagers. zlib had many severe vulnerabilities and if packages bundle copies of zlib, then every single one of it needs to be fixed _manually_. If packages link to it, we just fix up the system lib and are done. Also note that you (via Irrlicht) currently also ship a bundled copy of zlib.
    These things are difficult to track and will cause security issues on the long run, cause developers/packagers and users might not even be aware that they are affected.
  • maintenance: for you and for us. You modify it, we have to track down security issues, QA issues, build time issues and plain bugs not just for the system lib, but also for every modified copy in every possible package. So that you not think I'm talking stuff... this is already true for Irrlicht, cause the Makefile is messed up in several places and ignores users CFLAGS. I will send parts of those patches upstream anyway, but it then has to reach your bundled copy as well, maybe it does not or is even incompatible, cause your version is modified.
  • support: experience shows that people who bundle stuff don't accept bug reports for their bundled libraries although they might have modified them heavily (popular example is freeorion which "forked" gigi, but does not support it at all). Take it up with upstream they say. When I do it, upstream will tell me: erm, we don't support random forks. Maybe your version even introduces new bugs. No one will be responsible. This decreases support.
  • size: increased size, both in memory and on the disk, obvious

hiker wrote:So please, do not go this way, you will create a buggy version of STK, which will make players unhappy with STK, and causes us problems by people reporting the bugs you have (re-)introduced. If you do not want to support our included library, then please do not include STK, since your version will be buggy.

Oh, I forgot... this is the 5th reason not to bundle libs ;)
People will break your application and apply lolpatches.
hiker wrote:Instead ask your users to download our linux binaries.

No.

The bundled libs are no reason for Gentoo to not include STK, but if the situation gets worse, then packagers might just not care enough to spend time on it and keep track of the situation.


Besides this rant: STK works nicely and I see many gameplay improvements. Keep it up.
hasufell
 
Posts: 2
Joined: 12 Dec 2012, 20:56

Re: How I built SuperTuxKart with system libraries only

Postby Auria » 12 Dec 2012, 23:48

Well in a sense, you could consider that we have already forked irrlicht. Just name it stk-irrlicht or so and there you go. Irrlicht developers chose to make the library configurable at compile time, so I'm afraid there is no other way

We do intend to merge updates from irrlicht into our copy, so any valid bug that gets accepted and fixed in irrlicht will also appear in our version
Image
User avatar
Auria
STK Moderator
 
Posts: 2503
Joined: 07 Dec 2009, 03:52

Re: How I built SuperTuxKart with system libraries only

Postby hiker » 13 Dec 2012, 04:08

hasufell wrote:
hiker wrote:[*]they often break the API from one version to the next (bullet), and atm for example we do not even use (nor support) the latest bullet version.

That's not an argument at all. Distros have means to handle API breakage of libraries. (soname, any1?)
That should not be your concern at all and you can blame distributors to fix this.

I am not blaming distributors for that (or anything). But I agree, different versions can obviously distinguished if the distributor are willing to maintain that many versions of a library - I was more thinking of the followup problem: I can't see a good reason for us to spend effort to update bullet at this stage - it would just make a lot of work (porting, debugging), for no gain (unless we encounter a bug, or need a new feature). So for all I know STK might still be using bullet 2.79, when bullet reaches the 5.0 milestone ;) Would you still be willing to maintain bullet 2.79 at that time - esp. since each project might need its own special version of bullet? You are talking of wasted time further below - in these circumstances (admittedly somewhat theoretical, I don't think you will have that many applications that use bullet), would you prefer having to re-test X versions of bullet every time a new compiler is used for a release? As opposed to us just maintaining and managing this for you?

Re bullet some examples: we had to apply quite a few changes, which would certainly not be accepted upstream:
  • we had to remove SSE support (since it causes crashes - likely because some memory-misalignment in STK, which we never fixed, but since bullet performance is not an issue atm it's not important for us)
  • apply some other changes which are more or less STK specific (e.g. made some variables protected instead of private - though admittedly that might be accepted upstream)
  • I also remember that one physics process was changed in a new version, which might be 'more correct', but just broke STK. So we had to switch this new implementation off, another compile time change. This would be completely unnoticed (till you try to drive our karts, and perhaps then even under some rare circumstances).
  • one file in bullet broke when compiled with a certain compiler revision with default optimisation flags. We applied a work around (switched off one optimisation feature) for that and reported it - but still, your system libraries might just trigger that bug again. Bullet will potentially fix it in a new release, but in my experience won't release a bug fix version.


Generally, I don't think it's a good idea to link any program against a library it wasn't developed and tested with.

hiker wrote:[*]we apply bug fixes. Those are reported back to the developers, but might not be fixed before the next release of the corresponding library, which is too late for us (e.g. we only recently fixed a memory leak in bullet). Using a standard bullet will result in memory leaked constantly in each race.

That's understandable, somehow. However you should document that in the tarball (in README or INSTALL file) with a reference to the upstream bug report, so that packagers can be aware of the situation and unbundle it if your patches made it upstream.

Generally those things are documented in our commit log. Just get the log for the bullet/irrlicht tree, and you will see our changes with the reason for it. The way you suggest is actually more work for you: you have to keep track of any patches we apply, while otherwise we will do this for you ;)

This should always be considered an unresolved bug.
hiker wrote:[*]we need changes to compile-time constants (irrlicht), which the developers are not willing to make in their source code (and they recommended to use our own version)[/list]

That's the only real problem so far. There are solutions, but I can understand that these might not be viable:
1. fork it
2. switch to a different library (is there even one?)

You know _any_ bug free library? OK, there might be one or two (libhelloworld anyone?) - but suggesting to switch to a different library (even ignoring that it took us one year to switch in the first place) is just nonsense ;)

I know that these suggestions might be completely unrealistic.

Forking isn't, which is more or less what we did. Though I admit I don't like forks (it just means that development effort is duplicated, instead of all working towards a common solution ... ok, there are of course valid reasons for forks ... I don't want to get sidetracked here ;) ). We hope that we can stay as close as possible to official irrlicht - and perhaps one day they might even remove the hard-coded limits we need to change :)


Let me just sum up why bundling is bad and should be avoided if possible. I don't expect you to do something about it right now, but I hope that you still consider this situation a "bug":
  • security: bundled libraries are somehow out of the scope of packagers. zlib had many severe vulnerabilities and if packages bundle copies of zlib, then every single one of it needs to be fixed _manually_. If packages link to it, we just fix up the system lib and are done. Also note that you (via Irrlicht) currently also ship a bundled copy of zlib.
    These things are difficult to track and will cause security issues on the long run, cause developers/packagers and users might not even be aware that they are affected.


First of all, we re-package all zip files that will ever be used by irrlicht's included library. So even if a bad zip file would get submitted, it should be detected while re-packaging (with up-to-date zlib libraries). But I agree that this might be a concern for you, so just use:
Code: Select all
-DNO_IRR_COMPILE_WITH_ZLIB_

for your compile flags, and you are done. Similar flags exist for other included libraries. Note that one of the big advantages of irrlicht (at least from my point of view) is that it included many third party libraries, which makes it a lot easier for us to get new users to compile STK (less dependencies).

  • maintenance: for you and for us. You modify it, we have to track down security issues, QA issues, build time issues and plain bugs not just for the system lib, but also for every modified copy in every possible package. So that you not think I'm talking stuff... this is already true for Irrlicht, cause the Makefile is messed up in several places and ignores users CFLAGS. I will send parts of those patches upstream anyway, but it then has to reach your bundled copy as well, maybe it does not or is even incompatible, cause your version is modified.

  • We would welcome any patches that fixes that (the patch for FindFribidi.cmake is already applied - thanks for that!). Irrlicht development can be rather slow (one reason why we had to use an unreleased version before, and finally decided to maintain our own version). But yes, it is additional overhead, but I don't see any other choice.

  • support: experience shows that people who bundle stuff don't accept bug reports for their bundled libraries although they might have modified them heavily (popular example is freeorion which "forked" gigi, but does not support it at all). Take it up with upstream they say. When I do it, upstream will tell me: erm, we don't support random forks. Maybe your version even introduces new bugs. No one will be responsible. This decreases support.

  • I will gladly apply any patch that affects STK (assuming that it is also submitted upstream - we want to stay as close as possible to irrlicht).
  • size: increased size, both in memory and on the disk, obvious

  • I can't see many people having two irrlicht applications running at the same time tbh - besides, disk space nowadays is not really an issue (for this kind of memory - stripped libIrrlicht.a is 14MB).

    hiker wrote:So please, do not go this way, you will create a buggy version of STK, which will make players unhappy with STK, and causes us problems by people reporting the bugs you have (re-)introduced. If you do not want to support our included library, then please do not include STK, since your version will be buggy.

    Oh, I forgot... this is the 5th reason not to bundle libs ;)
    People will break your application and apply lolpatches.

    We are using static libs, so I admit I am not sure what you mean here.

    hiker wrote:Instead ask your users to download our linux binaries.

    No.

    The bundled libs are no reason for Gentoo to not include STK, but if the situation gets worse, then packagers might just not care enough to spend time on it and keep track of the situation.

    I fully understand this. If irrlicht should be improved to get rid of the compile time constant (not sure if this is possible, I just assume it could be done), we might consider it (though having had problems in the past with the speed of irrlicht development I am not guaranteeing anything here ;) ). Then again, I've already seen some code I wanted to re-use (caching of meshes), but I can't without some changes to irrlicht, which I am not sure the developer would accept (but I will certainly try).

    Besides this rant: STK works nicely and I see many gameplay improvements. Keep it up.

    Thanks a lot - not only for adding STK to Gentoo, but also for the time to tell your side of the story. In an ideal world I would gladly agree with most what you wrote - but unfortunately at this stage I don't see any other option that will guarantee a bug-free experience for players.

    Is there anything we can do to help you? Should we include any config files or so - e.g. to make it easier for you to disable the included png/zlip/jpg libs of irrlicht?

    One other quick question: do you have any stats about the number of downloads of STK from your servers? I would be interested to know how many linux downloads there are that we don't know about.

    Cheers,
    Joerg
    Image
    hiker
    STK Moderator
     
    Posts: 1300
    Joined: 07 Dec 2009, 12:15
    Location: Melbourne, Australia

    Re: How I built SuperTuxKart with system libraries only

    Postby hasufell » 13 Dec 2012, 17:53

    Auria wrote:Well in a sense, you could consider that we have already forked irrlicht. Just name it stk-irrlicht or so and there you go. Irrlicht developers chose to make the library configurable at compile time, so I'm afraid there is no other way

    That's not what I consider a proper fork as a distributor. For this to make sense you would have to a) accept general bug reports for this library fork and b) ensure that other packages that use the old library are also compatible with your version. You just fork it for your own needs. Such things will never replace the original library.
    Auria wrote:We do intend to merge updates from irrlicht into our copy, so any valid bug that gets accepted and fixed in irrlicht will also appear in our version

    It's still increased maintenance on both ends.
    hiker wrote:So for all I know STK might still be using bullet 2.79, when bullet reaches the 5.0 milestone ;) Would you still be willing to maintain bullet 2.79 at that time - esp. since each project might need its own special version of bullet?

    Yes, cause it's under MY control then. We did this a long time for "boost" until recently, but that's another story (the policy for boost changed because most fixes are trivial so instead of having 5 boost versions installed in parallel we fix up the packages). As far as I can speak for gentoo, that is definitely no problem. Might even be easier on a binary distro.

    Also note that you can (and should) make bundled libraries optional unless you modified them ofc. It's perfectly fine if you start bundling more and provide a cmake option to turn it off. This way you can ensure that people on random distros can compile it OOTB, but also that packagers will not go mad.

    hiker wrote:Re bullet some examples: we had to apply quite a few changes, which would certainly not be accepted upstream:
    • we had to remove SSE support (since it causes crashes - likely because some memory-misalignment in STK, which we never fixed, but since bullet performance is not an issue atm it's not important for us)
    • apply some other changes which are more or less STK specific (e.g. made some variables protected instead of private - though admittedly that might be accepted upstream)
    • I also remember that one physics process was changed in a new version, which might be 'more correct', but just broke STK. So we had to switch this new implementation off, another compile time change. This would be completely unnoticed (till you try to drive our karts, and perhaps then even under some rare circumstances).
    • one file in bullet broke when compiled with a certain compiler revision with default optimisation flags. We applied a work around (switched off one optimisation feature) for that and reported it - but still, your system libraries might just trigger that bug again. Bullet will potentially fix it in a new release, but in my experience won't release a bug fix version.

    I think it might even be nice to have a seperate file in the "lib" subfolder, explaining the issues just like you did.

    Another thing you might consider for bundling properly: apply the patches against upstream version at compile-time. No need to diff anything or walk through some repository logs then. That's how distributors do it too. We don't just upload modified versions, we apply patches at build time, so upstream, developers and users can view them.

    I don't consider this much more maintenance.
    hiker wrote:
    hiker wrote:[*]we apply bug fixes. Those are reported back to the developers, but might not be fixed before the next release of the corresponding library, which is too late for us (e.g. we only recently fixed a memory leak in bullet). Using a standard bullet will result in memory leaked constantly in each race.

    That's understandable, somehow. However you should document that in the tarball (in README or INSTALL file) with a reference to the upstream bug report, so that packagers can be aware of the situation and unbundle it if your patches made it upstream.

    Generally those things are documented in our commit log. Just get the log for the bullet/irrlicht tree, and you will see our changes with the reason for it. The way you suggest is actually more work for you: you have to keep track of any patches we apply, while otherwise we will do this for you ;)

    Inconvenient and improperly, see above. At least for the release tarball. Cut a patch, even if it's a single file and summarize the changes. That should take no more than 10minutes.

    We are talking about a consistent release tarball here. If you don't fork it properly, then patch it properly.
    hiker wrote:Generally, I don't think it's a good idea to link any program against a library it wasn't developed and tested with.

    You document what you tested your software with and that's it. Rest is up to the distributor who does this kind of stuff on a daily basis and by experience I must say you exaggerate. If we would do as you suggest we would have to remove probably more than half of the software from our repository.

    I'v even heard upstream developers say that compiling on your own may break their application. Erm.

    hiker wrote:
    hiker wrote:[*]we need changes to compile-time constants (irrlicht), which the developers are not willing to make in their source code (and they recommended to use our own version)[/list]

    That's the only real problem so far. There are solutions, but I can understand that these might not be viable:
    1. fork it
    2. switch to a different library (is there even one?)

    You know _any_ bug free library? OK, there might be one or two (libhelloworld anyone?) - but suggesting to switch to a different library (even ignoring that it took us one year to switch in the first place) is just nonsense ;)
    Forking isn't, which is more or less what we did. Though I admit I don't like forks (it just means that development effort is duplicated, instead of all working towards a common solution ... ok, there are of course valid reasons for forks ... I don't want to get sidetracked here ;) ). We hope that we can stay as close as possible to official irrlicht - and perhaps one day they might even remove the hard-coded limits we need to change :)

    as said earlier, it is not a real fork

    but I see that you seem to care about your changes going upstream and that's relieving.

    hiker wrote:
    Let me just sum up why bundling is bad and should be avoided if possible. I don't expect you to do something about it right now, but I hope that you still consider this situation a "bug":
    • security: bundled libraries are somehow out of the scope of packagers. zlib had many severe vulnerabilities and if packages bundle copies of zlib, then every single one of it needs to be fixed _manually_. If packages link to it, we just fix up the system lib and are done. Also note that you (via Irrlicht) currently also ship a bundled copy of zlib.
      These things are difficult to track and will cause security issues on the long run, cause developers/packagers and users might not even be aware that they are affected.


    First of all, we re-package all zip files that will ever be used by irrlicht's included library. So even if a bad zip file would get submitted, it should be detected while re-packaging (with up-to-date zlib libraries). But I agree that this might be a concern for you, so just use:
    Code: Select all
    -DNO_IRR_COMPILE_WITH_ZLIB_

    for your compile flags, and you are done. Similar flags exist for other included libraries. Note that one of the big advantages of irrlicht (at least from my point of view) is that it included many third party libraries, which makes it a lot easier for us to get new users to compile STK (less dependencies).

    That's not the point at all. This was merely an _example_. The more stuff is bundled the higher the risk that vulnerabilites will go unnoticed or unfixed, always.

    hiker wrote:
  • maintenance: for you and for us. You modify it, we have to track down security issues, QA issues, build time issues and plain bugs not just for the system lib, but also for every modified copy in every possible package. So that you not think I'm talking stuff... this is already true for Irrlicht, cause the Makefile is messed up in several places and ignores users CFLAGS. I will send parts of those patches upstream anyway, but it then has to reach your bundled copy as well, maybe it does not or is even incompatible, cause your version is modified.

  • We would welcome any patches that fixes that (the patch for FindFribidi.cmake is already applied - thanks for that!). Irrlicht development can be rather slow (one reason why we had to use an unreleased version before, and finally decided to maintain our own version). But yes, it is additional overhead, but I don't see any other choice.

    Thanks, I hope you didn't apply without testing, I can only test on linux ;)

    hiker wrote:
  • support: experience shows that people who bundle stuff don't accept bug reports for their bundled libraries although they might have modified them heavily (popular example is freeorion which "forked" gigi, but does not support it at all). Take it up with upstream they say. When I do it, upstream will tell me: erm, we don't support random forks. Maybe your version even introduces new bugs. No one will be responsible. This decreases support.

  • I will gladly apply any patch that affects STK (assuming that it is also submitted upstream - we want to stay as close as possible to irrlicht).
  • size: increased size, both in memory and on the disk, obvious

  • I can't see many people having two irrlicht applications running at the same time tbh - besides, disk space nowadays is not really an issue (for this kind of memory - stripped libIrrlicht.a is 14MB).

    ok 14mb for your app, what about the rest of the packages where someone thought "oh well, it's just 50mb more, who cares about 50mb these days".

    This is simply a principle.

    hiker wrote:
    hiker wrote:So please, do not go this way, you will create a buggy version of STK, which will make players unhappy with STK, and causes us problems by people reporting the bugs you have (re-)introduced. If you do not want to support our included library, then please do not include STK, since your version will be buggy.

    Oh, I forgot... this is the 5th reason not to bundle libs ;)
    People will break your application and apply lolpatches.

    We are using static libs, so I admit I am not sure what you mean here.

    I was referring to why this thread started.

    hiker wrote:
    Besides this rant: STK works nicely and I see many gameplay improvements. Keep it up.

    Thanks a lot - not only for adding STK to Gentoo, but also for the time to tell your side of the story. In an ideal world I would gladly agree with most what you wrote - but unfortunately at this stage I don't see any other option that will guarantee a bug-free experience for players.

    Is there anything we can do to help you? Should we include any config files or so - e.g. to make it easier for you to disable the included png/zlip/jpg libs of irrlicht?

    One other quick question: do you have any stats about the number of downloads of STK from your servers? I would be interested to know how many linux downloads there are that we don't know about.

    I'm afraid no, but it would definitely be nice. We were even thinking about something like "build charts" where we get information (ofc only if the user wants to) when someone builds something, so we can keep track of popularity of applications, assign manpower more efficiently.
    But well, in the end... you see it by bug reports :P


    Anyhow, as you can see... supertuxkart has been updated in gentoo. This is no blocker for us. However I want you to understand why we don't like such situations. That's all.
    There are far worse examples... believe me.
    hasufell
     
    Posts: 2
    Joined: 12 Dec 2012, 20:56

    Re: How I built SuperTuxKart with system libraries only

    Postby charlie » 13 Dec 2012, 18:35

    hasufell wrote:
    hiker wrote:[Libraries] often break the API from one version to the next (bullet), and atm for example we do not even use (nor support) the latest bullet version.

    That's not an argument at all. Distros have means to handle API breakage of libraries. (soname, any1?)
    That should not be your concern at all and you can blame distributors to fix this.

    A utopian statement said by somebody who obviously has no real world experience developing for and supporting a lot of different platforms and all the user reports that go with it.
    Free Gamer - it's the dogz
    Vexi - web UI platform
    User avatar
    charlie
    Site Admin
     
    Posts: 1523
    Joined: 02 Dec 2009, 11:56
    Location: Manchester, UK

    Re: How I built SuperTuxKart with system libraries only

    Postby Auria » 14 Dec 2012, 04:45

    Overall I agree in principle but let me disagree with :

    You document what you tested your software with and that's it. Rest is up to the distributor who does this kind of stuff on a daily basis and by experience I must say you exaggerate.


    we speak from actual experience ;) several distributions, including at least debian and ubuntu, others also I think but I lost track, distributed buggy packages of 0.7.x because they wouldn't statically link irrlicht as we asked and used a system irrlicht instead. We were the ones receiving several bug reports about crashes and distorted karts, and everytime installing from our website fixed the issue. I'm sorry, if the developers say that STK needs a specific irrlicht to work, I really don't think it's OK for a packager to decide to use anything else - simply because we eventually receive the bug reports
    Image
    User avatar
    Auria
    STK Moderator
     
    Posts: 2503
    Joined: 07 Dec 2009, 03:52

    Who is online

    Users browsing this forum: No registered users and 5 guests