Suggestion to any Linux Devs who will read this..

E

Eric Ross

Guest
This may not be a new one, but here it goes..

Basically, 'force' any third party libraries such as libSDL to name a GENERIC .so library and keep the version numbers in comments in the library itself and NOT the name. In such a scenario, if I were to try to play a game looking for 'libSDL1.2' but the latest libSDL2.0 exists, this could be a replacement for asking the less contemporary user to create a symlink to it. I think it could reduce many issues with incompatibilities among distros. If there is a problem and the application or game is well written, it will bomb and log an error displaying 'newer library version required', 'library obsolete', '64bit version incompatible', or other message. My ultimate goal here is to be able to distribute or play binaries without running into dependency heck.

Does this make sense and could it be implemented? I've had to symlink a libray to a few games, X9 plane simulator comes to mind.

Thanks.
-ER
 


This may not be a new one, but here it goes..

Basically, 'force' any third party libraries such as libSDL
The problem here is the word "force"... FOSS is not the same as proprietary software, different development model and different goals/requirements.

http://xkcd.com/927/

Also what constitutes a "3rd party library"? And why do you feel that the SDL library falls into this category?

to name a GENERIC .so library and keep the version numbers in comments in the library itself and NOT the name.
The current system of symlinking works well. Hiding the version inside the binary file is not that useful. With the version string included in the lib file name and symbolic links it works best for everyone and also works easily with package managers.

In fact in many cases, it's your particular game which is actually "3rd party" and has been built against older libs. You can always store the older versions it requires in the /usr/local directory structure, or package it and install it...

In such a scenario, if I were to try to play a game looking for 'libSDL1.2' but the latest libSDL2.0 exists, this could be a replacement for asking the less contemporary user to create a symlink to it. I think it could reduce many issues with incompatibilities among distros. If there is a problem and the application or game is well written, it will bomb and log an error displaying 'newer library version required', 'library obsolete', '64bit version incompatible', or other message. My ultimate goal here is to be able to distribute or play binaries without running into dependency heck.
Honestly - sounds like windows stuff from a windows perspective. GNU/Linux is a source based OS - distributors just do the compiling for you. The nature of open source is that it's source based and there's no getting away from that.

If you have libSDL2.0 installed by the distribution, then just build or install libSDL1.2. Even if you install these in /usr/lib , they will be named differently, so no confusion.
Does this make sense and could it be implemented? I've had to symlink a libray to a few games, X9 plane simulator comes to mind.

Thanks.
-ER
If it's any consolation - by symlinking, you're doing the right thing.
 
SDL is a third party IMO, distros can include in their repo's if they want to (or not).
 
Then pretty much every package in every distros repos must be "3rd party". Can you list some 1st and 2nd party libs?
 
I think the issue is changes in the application binary interface (ABI). If the ABI is changed from one library version to the next, the new version can't work with software compiled against a different version. So you MUST put the version in the name to be sure you get the right one.

This has been a minor complaint I've had with Linux. It's one of the few areas where Windows has some superiority over Linux. I think I've read that Solaris also does a better job of keeping the ABIs unchanged.
 

Members online


Top