Page 2 of 2
Posted: Mon Feb 13, 2012 11:58 pm
Same issue like that one in the HumbleBundle. PLEASE dont ship libSDL, set it as package dependency for the deb/rpm. that will fix some things on the opensource radeon driver (and maybe other) and is more secure. i always have to delete
from the Packages to play. The same with all other games that ship a own version of this :/
I love your games but hate to install at the moment
Posted: Tue Feb 14, 2012 1:09 am
Oh, they do that for the rpms and debs, too? Yeah, that's really not the way to go. For the other distribution methods, you kind of have to include the libs, there are distributions out there that don't ship with SDL installed by default. Still, it's better to make the system installed ones get preferred.
Posted: Tue Feb 21, 2012 11:24 pm
Except that they know the game works with that particular version of a library they ship. It's possible for example that there's a bug in the library and the game uses a workaround, but a year later the bug gets fixed and the game no longer works with that version. In that case the game would work as before if it used the version it supplied.
Posted: Thu Feb 23, 2012 2:46 am
TarrasQ wrote:Except that they know the game works with that particular version of a library they ship. It's possible for example that there's a bug in the library and the game uses a workaround, but a year later the bug gets fixed and the game no longer works with that version. In that case the game would work as before if it used the version it supplied.
I don't know much about the various Linux package management systems, but I assume that when one sets a dependency, one can require a specific version. Thus if Multiwinia requires libSDL version x.y, and the user has x.(y+1) installed, the package manager should also install x.y. Is that incorrect?
Posted: Thu Feb 23, 2012 11:07 am
Correct. Usually, the package manager will not allow different compatible versions of a library installed at once (say, SDL 1.2.10 and SDL 1.2.12), but in the relevant and highly hypothetical case that the older version has an important, long-unfixed bug that application developers needed to work around in a way that is incompatible with the fixed version, parallel installation would be allowed, just like you can have different libstdc++ versions in parallel.
I say highly hypothetical because the libraries in question here are old and venerable and don't have bugs that need workarounds by the application. The bugs they do have, especially SDL, are more of the "Hardware/window manager/sound library XYZ not supported properly", in which case you absolutely want a never version of the library your system installed to override any included one.
And even if there is such a bug you need to work around and you fear a future update is going to break your app, you then fix the bug in the library (usually easier than working around it) and include a fixed version. Which is what Mac DEFCON does. Ideally, you automatically fall back to the system library if the bug is fixed there.