No point in using a library subdirectory
Provides functionality for gaming input devices
Brought to you by:
erazor_de
Menu
▾
▴
#3 No point in using a library subdirectory
I am working on a libgaminggear Debian package and noticed that it uses a library subdirectory and modifies the run-time linker search path to include that. Debian considers that a packaging error for reasons described at https://lintian.debian.org/tags/package-modifies-ld.so-search-path.html. I plan to patch the source in my package to avoid this, but I thought you might want to know about the issue.
roccat-tools uses it's subfolder /usr/lib/roccat to search for it's eventhandler plugins.
Originally I wanted to generalize and transfer the eventhandler and it's plugin handling from roccat-tools to libgaminggear, with /usr/lib/gaminggear-* being the search path for manufacturer/device specific plugins from other packages.
I don't have the time for such a big restructuring at the moment.
Moving the libgaminggear libraries to /usr/lib is save in the current state.
I don't want to remove the subfolder because in the future I might need it for mentioned reason.
The possibility of conflicting libraries in /usr/lib and /usr/lib/gaminggear-* is low.
Possible fix would be to check if the plugin libraries have to be in the ld.so search path to be successfully loaded. If not, I would put the plugin libraries in a dedicated folder under /usr/share and the library subfolders /usr/lib/gaminggear- and /usr/lib/roccat could be suspended.
Another option is you could set an rpath in the pkg-config file. That lets you use a private directory without having to modify the ld.so search path for the rest of the system.
Patched libgaminggear to not use subfolder anymore. Patch