Bug 118911 - revdep-rebuild doesn't find /usr/share/games/glest/lib/glest
|
Bug#:
118911
|
Product: Gentoo Linux
|
Version: 2005.1
|
Platform: x86
|
|
OS/Version: Linux
|
Status: RESOLVED
|
Severity: normal
|
Priority: P2
|
|
Resolution: FIXED
|
Assigned To: games@gentoo.org
|
Reported By: evert.gentoo@planet.nl
|
|
Component: Games
|
|
|
URL:
|
|
Summary: revdep-rebuild doesn't find /usr/share/games/glest/lib/glest
|
|
Keywords:
|
|
Status Whiteboard:
|
|
Opened: 2006-01-13 12:35 0000
|
After updating dev-libs/xerces, glest doesn't work anymore. I had this before
and after re-emerging glest it ran OK again. But revrep-rebuild doesn't find
glest, which is missing a library, I guess because it doesn't check the
/usr/share/games/glest/lib dir...
$ glest
./glest: error while loading shared libraries: libxerces-c.so.26: cannot open
shared object file: No such file or directory
# revdep-rebuild -p
[...cut...]
Dynamic linking on your system is consistent... All done.
$ ldd /usr/share/games/glest/lib/glest
linux-gate.so.1 => (0xffffe000)
libSDL-1.2.so.0 => /usr/lib/libSDL-1.2.so.0 (0xb7f2d000)
libpthread.so.0 => /lib/libpthread.so.0 (0xb7eda000)
libGL.so.1 => /usr/lib/opengl/nvidia/lib/libGL.so.1 (0xb7e6c000)
libGLU.so.1 => /usr/lib/libGLU.so.1 (0xb7df3000)
libm.so.6 => /lib/libm.so.6 (0xb7dd0000)
libxerces-c.so.26 => not found
libvorbis.so.0 => /usr/lib/libvorbis.so.0 (0xb7da9000)
[...cut...]
By default, revdep-rebuild won't even search GAMES_BINDIR or GAMES_LIBDIR.
Perhaps the games eclass could add those to SEARCH_DIRS in gamesenv() or to a
new file in /etc/revdep-rebuild.
Created an attachment (id=87296) [details]
Patch for glest-2.0.0 ebuild
/usr/games/bin and /usr/games/lib are currently searched by revdep-rebuild.
What is not searched in this case is /usr/share/games/glest/lib. Attached patch
for the glest-2.0.0 ebuild installs a SEARCH_DIRS directive into the
/etc/revdep-rebuild directory.
You're right, I suppose it gets that from PATH and LDPATH, I just assumed it
only checked SEARCH_DIRS.
I think this is not the fault of revdep-rebuild, but it's the fault of the
glest ebuild! The directory /usr/share is supposed to only include architecture
independent files, so no binary executables or libs. Now see:
# file /usr/share/games/glest/lib/glest
/usr/share/games/glest/lib/glest: ELF 32-bit LSB executable, Intel 80386,
version 1 (SYSV), for GNU/Linux 2.4.1, dynamically linked (uses shared libs),
for GNU/Linux 2.4.1, stripped
This was the case in glest-1.2.1.2 and is now the case again in glest-2.0.0!
I think the easiest way to fix this is to let the ebuild move
/usr/share/games/glest/lib/glest to /usr/games/lib/ and create a softlink
/usr/share/games/glest/lib/glest which points to /usr/games/lib/glest.
This way, /usr/share would not only get rid of a binary but revdep-rebuild
would also have no problem finding the executable anymore!
Furthermore, (a bit off topic, but) I see the directory
/usr/share/doc/glest-2.0.0 is empty.
# equery f glest |grep doc
/usr/share/doc
/usr/share/doc/glest-2.0.0
I don't know if there is a special reason for this, but if there isn't, the
ebuild can skip the creation of that directory too!
Ideally, the game would write to $HOME and wouldn't need a wrapper.
Should be fixed by glest-2.0.0-r1, thanks to Tristan Heaven