Could you not just have the noarch package put stuff in /usr/share and have the arch-specific one make symlinks to it in /usr/lib?

The way we do this in Debian is to install arch-independent ("noarch") data in /usr/share (with symlinks in /usr/lib) and binaries in /usr/lib, and tell ioquake3 that its base path is under /usr/lib.

In Debian, lib64 isn't used, but in principle you could have symlinks from /usr/lib64 to /usr/share in the arch-independent data packages too, and tell 64-bit ioquake3 binaries that their base path is under /usr/lib64.

We use wrapper scripts in /usr/games (or you could put them in /usr/bin) so we can share one copy of ioquake3 and one copy of ioquake3-server between OpenArena and Quake III Arena; the wrapper scripts change fs_basepath, com_basegame, com_homepath, com_legacyprotocol, com_protocol, com_gamename according to the game being used.

I haven't tried this for Reaction, Urban Terror or Smokin' Guns; they might need engine patches.

The Fedora packaging for ioquake3 (I think they call it "quake3" there) is also worth looking at.

RPMlint is so strict that it does not even allow the symlink in noarch packages. If make the symlink in the non-data package it will moan that the target does not exist.

http://www.etlegacy.com/issues/81 is updating it's cmake for FHS compliance.

By the way, https://build.opensuse.org/package/show?package=urbanterror-data&project=games might be interesting for you Debian guys as non-free stuff is also not allowed on openSUSE build service and 1.2 GB RPMs might bloat the mirrors. So I worked around this using http://sourceforge.net/projects/autodownloader/ and some post rpm scripts. There are quite many projects using a free engine, but non-commercial/Freeware/no-license-at-all game files. There is still room for improvement and I am not 100% happy, but it works.

It seems that you can enforce FHS compliance with

make copyfiles COPYBINDIR=/usr/bin COPYDIR=/usr/share

at least for smokin-guns.

Reaction needs a patch that adds DEFAULT_LIBDIR and COPYLIBDIR, see https://bugzilla.icculus.org/show_bug.cgi?id=5780

Yeah, once Reaction leaves Beta I'd want to package and maintain it myself for atleast Fedora and this could become a real issue there as well.
I second ioq3 becomes FHS compliant, just so that I can avoid making changes to Reaction that will conflict with what ioq3 does at some later day in the future.

Since I've run into the same problem while trying to create a proper Gentoo .ebuild for ioquake3, here are my notes on the issue;

The ioq3 engine uses different kinds of libraries.
Some of them are the renderer libraries (opengl1 and rend2 so far), which are currently only used by ioq3 itself. However one could imagine that (non-standalone) ioquake3 games want to use the ioquake3 binary, but provide their own renderer.
Then there are system libraries like zlib, SDL, OpenAL, Vorbis, Speex, Ogg etc. These are special in so far that they are usually bundled for Windows releases only.
Finally there's a special case of libraries, the VM ones. While the game logic is usually compiled into QVMs in the Q3 ecosystem, some variants of idtech 3 only support shared libraries.


So far a possible file tree could look like the following;

/usr/share/quake3/baseq3/
	pak0.pk3  pak2.pk3  ...
/usr/bin/
	ioquake3 ioq3ded
/usr/lib/quake3/
	renderer_opengl1_x86_64.so  renderer_rend2_x86_64.so
/home/someuser/.quake3/somemod/
	qagamex86_64.so  ...

Where the base installation is within fs_basepath (plus fs_apppath on Mac) and user-specific settings and (automatically downloaded) mods are stored in fs_homepath.

By adding a new fs_libpath (for /usr/lib/quake3 in this example) one would solve that issue. It could just have the same value as fs_basepath by default (configurable via Makefile) so that e.g. bundled Windows variants or portable versions continue to work.
The VM loading logic would need to be tweaked. Instead of loading shared library VMs from fs_basepath they would have to be loadeded from fs_libpath, while QVMs would still be loaded from fs_basepath. The QVMs should also be loaded from fs_homepath just like now, so (auto-)downloaded mods continue to work. It's arguable whether shared library VMs should be loaded from fs_homepath, but this would allow for more flexible server setups as an example.


I have code for the fs_libpath addition at https://github.com/robo9k/ioq3/compare/feature;libpath which has been shortly discussed on #ioquake3, feedback appreciated.
I'm currently investigating how to properly modify VM library loading, as fs_libpath should not be part of fs_searchpaths.

No. I don't feel like there is a good argument to be made for FHS compliance. The solution of putting ioquake3 pieces into different directories is absurd and will cause more harm than it is worth. Distributions, if they feel it's worthwhile, can always apply whatever patch they choose.