flightgear-0.9.10 has a runtime dependency on media-libs/freealut (specifically any library providing AL/alut.h) which is not listed in the ebuild. This causes a compile-time failure and inability to start the game by issuing the command fgfs, the latter failing during or immediately after "initializing subsystems" with the following error on stderr: fgfs: symbol lookup error: fgfs: undefined symbol: alutLoadWAVFile As flightgear (even 0.9.10) worked for me before, this looks like a mistake in updating the fg ebuild, or a related one. Is virtual/glut supposed to provide ALUT? The patch below fixes this on my system (using the default-linux/amd64/2005.0 profile) but admittedly is something of a kludge. --- /usr/portage/games-simulation/flightgear/flightgear-0.9.10.ebuild 2006-04-08 03:45:49.000000000 +0200 +++ /usr/local/portage/games-simulation/flightgear/flightgear-0.9.10.ebuild 2006-10-15 23:35:40.000000000 +0200 @@ -19,7 +19,8 @@ RDEPEND="virtual/glut ~dev-games/simgear-0.3.10 - >=media-libs/plib-1.8.4" + >=media-libs/plib-1.8.4 + media-libs/freealut" DEPEND="${RDEPEND} >=sys-apps/sed-4"
Hardcoding dependency on media-libs/freealut is not acceptable; that's the whole point of virtual/glut.
freealut isn't glut
(In reply to comment #1) > Hardcoding dependency on media-libs/freealut is not acceptable; that's the > whole point of virtual/glut. (In reply to comment #2) > freealut isn't glut Frankly, I don't care what virtual ebuilds provide which specific packages. (virtual/glut obviously does not pull in media-libs/freealut, or ALUT would have been on my system; looking at the ebuild file also confirms this) I just want the applications I have emerged previously - from source, even - to keep working. There is no need to tell me that the exact steps I took to correct on my own system what is obviously a portage tree deficiency are "not acceptable". If you have a better solution that should go into the official tree, that is perfectly fine by me. The patch I included should indicate clearly enough that the modified ebuild is from a portage overlay, not in the official tree.
simgear depends on freealut so that should be enough
No bugs here
I hate implicit deps. I'll add this since it'll break installs where simgear comes from a binpkg and flightgear is being compiled. We run into this sort of thing all the time with Release Engineering and it makes me want to tsab people who use implicit deps.
I'll take it
OK. It actually isn't an implicit dependency. It is a required runtime dependency. FIXED in CVS...
