Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
update debian stuff, make distro scripts not debian specific #1135
This is a deep revamp of debian scripts, but in a way the work can benefit to other distributions or packaging technologies.
I'm not doing it to support Debian, we would still answer for people having trouble with it that's unsupported. I'm doing it to be sure what we have in repos is on-par with our current game status.
Everything was lacking years behind: there was still references to the
If someone wants to support a distribution or build a package, the gap is far lower than before.
I've tested it successfully on Ubuntu 19.10.
Maybe the arch package can be revamped to rely on those scripts too, ping @Viech.
A systemd service is now shipped for Debian, maybe some work can be done to make it instanciable.
The server config sample was updated, it now adds bots etc. So people can have a working example to refer to.
For the moment I've set the bot names I use on my own server because I'm lacking imagination, feel free to suggests others.
The Debian package seed builds and ships both nacl and native c/sgame, it's not really useful for average user since by default c/sgame is loaded from nexe from dpk, but those are shipped so it's possible to run Unvanquished the alternate ways (like debugging).
It looks like I'm not able to build Unvanquished with breakpad on Ubuntu 19.10 anymore.
I faced weird issues by building c/sgame nexes with
For this reason I did a dirty hack where the usual build disables nexe build and a nexe are built in a separate directories after that, with a cleaned-up environment. So, files that are not nexes are built the way Debian expects them and nexe are not.
For reference, this is the linkage error:
I've discovered that debian helpers set this environment variable this way:
This environment variable get translated this way by CMake in
Main reason is knowledge and polishing. This raises some corner cases issues that would make the engine design better if fixed¹.
Also such uncommon usage usually raises bugs some time before common usage raises them: we now have a good example of situation where nacl build does not work out of the box. One day we may have nacl build issue on common scenario.
In any way, most of the work was done on the launch scripts, which I rewrote purposely to be reusable on any distro.
While I'm fully committed to the updater, being able to build a flatpak or something like that would not be bad.
¹ For example it's interesting to discover that to be able to fix mutilib (something we really don't have to care about since we usually don't run shared libs gamecode) the fix is the same as to be able to build game and engine separately (something that I care about). The same fix would fix both: this fix would be multi libpath support. What's interesting in that example is that a single possible feature can fix more than one issue, and very unrelated issues. Fixes that fix other issues for free usually means they are design fixes.
Thanks for the context, sounds good.
Could you point out the updated server template? It's hard to find since there are so many files... If you're talking about the .cfg files, that sounds interesting to integrate into the engine or other installation methods somehow.
Client/Server/TTY launch helper:
Example of systemd unit:
Yes, either dump a template at first startup, either hardcode some value people can override.
The later sounds better, for example to define default bot names.