The cgame-x86_64.nexe file is the gamecode executable in NaCl format. It's the format for gamecode (and mod) in Unvanquished. Unvanquished runs that NaCl code in a sandbox, so it means you can safely run any gamecode from an arbitrary server.
Unlike the Quake mods that uses QuakeC, mods are not scripted.
Unlike the Quake3 mods that uses QVM, mods can use advanced modern C++ language and standard C++ libs (for example the Unvanquished game client is compiled against libRocket).
Unlike the Wolf:Et mods that are plain solibs downloaded and executed without any check from arbitrary servers, that code is sandboxed.
So, game and mod developers get a nice and modern C++ development platform with native execution rate and access to many C++ libraries, while the users do not run that code without protection. For example the only file system calls allowed to the game code are the read-only access to the VFS (only the files in pkg/directory, and files in pk3 archives in pkg/ directory).
So, it's very good for the Unvanquished project and very good for Unvanquished users, but you get the problem while packaging for distro, I like distro packages, but there is some issues there :
- The game clients must use the same binary than server and other clients (from other Linux distros, from Windows, from MacOS) to prevent cheating…
- Distro generally does not allow to package binaries they don't build themselves.
- Distro generally does not allow packages that can't run out of the box without downloading extra stuff that cannot be placed in repositories.
There is some exceptions like FlashPlayer, but the word “exception” means something.
By the way, Dæmon can handle multiple concurrent files even with same name, and also allows to uses advanced versioning scheme.
So, for example, you can build a unvanquished_0.48fedora.pk3 that contains your own fedora-compiled nexe, the fedora user will be able to enjoy a full game without having to download third-party binaries, and when he connects to a server, he will autodownloads the unvanquished_0.48.pk3 package from the server (like if it were a mod) to run it while playing online. So, your fedora compiled nexe will not conflict with the official one, and your package will works out of the box. Because Unvanquished knows how to deal with multiple files that have the same name, you can rename your package unvanquished_0.48.pk3, but it's fair to add a version (0.48version < 0.48).
Also, all the unvanquished_ packages contain old binaries plus some stuff, you probably want to make a standalone 0.48fedora package that contains only the last nexes you built, plus the other stuff that are not binaries, from all the older unvanquished_ packages, without all these packages in DEPS file.
So, this fixes the "how I can build official package that cannot rely on external binary to run right after the installation from repository" problem, but it does not fix the issue "how I can run an arbitrary nexe downloaded from the internet" while having SELinux activated. By the way, the NaCL sandbox and SELinux are in competition there, they both wants to protect you in a similar way… I have no solution, perhaps you can see how the chromium (the web browser) package do.
Edit: So to answer to that question:
Maybe here a developer can help in say why cgame-x86_64.nexe is extracted from .pk3.
The cgame nexe is the client game code, it's extracted from the pk3 at map load, and it's only extracted from the pk3 if the pk3 on the client side is the same as the one loaded by the server, so it means the cgame nexe used by the player is the same as the server, so it means all players use the same cgame nexe when playing on the same server. So, the cgame nexe is extracted from the pk3 to ensure everyone on the same server uses the same cgame code to avoid cheating.