Re: Quake packaging [Re: Debian Games Team Policy]
On 25/05/11 15:53, Simon McVittie wrote:
> You only need a second layer of shell wrapper in the engine package if Quake 1
> engines are not generally command-line-compatible with each other, or with the
> original id Software Quake 1 engine.
It seems from a rough survey that most engines are broadly command line
compatible, at least far enough to get the game working consistently.
Side question: would you say the game should launch in fullscreen by
default? Is it worth enforcing consistency on that?
> A slight simplification which would avoid having to think about virtual
> packages or alternatives until we get a second engine:
>
> * create a separate quake package with a launcher script that runs quakespasm
> (the binary) directly, with whatever command-line options are needed to make
> it use quake-data; depend directly on quakespasm
ACK. I will start this asap.
Should quakespasm still Provide 'quake-engine' for the moment, as
quake-data produced by game-data-packager in unstable already contains*
this virtual package?
> * if we ever get a second quake engine (but are any of the others good enough
> to bother?), this is the right time to start thinking about alternatives
> and virtual packages: change the quake launcher so it runs the quake-engine
> alternative, and define the quake-engine alternative as "anything with
> the same command-line interface as the original id Quake engine", and
> the quake-engine virtual package as "provides the quake-engine alternative"
Mmm, I looked into some other engines a bit. Sadly proquake seems way
too broken to package even though it looks like a nice engine. (No
upstream VCS, binaries shipped in tarball, doesn't compile on sid
without makefile tweaks, at least two segfault bugs to get past before
it will even run - I hacked around one of them only to hit the next :))
[The niche it would fill is a deathmatch-focused engine with wide server
compatibility, which Quakespasm doesn't aim for. I would probably look
at Qrack for this next.]
Darkplaces is definitely worth including due to the significant
graphical enhancements and large userbase. #319599 claims that
darkplaces and nexuiz are essentially the same and that we should rather
make nexuiz use darkplaces as its engine. I agree with this goal, but
I'd be (pleasantly!) surprised if nexuiz hasn't incompatibly diverged
from darkplaces at this point. Maybe the nexuiz maintainer knows the
answer to this? In any case, I can't use the nexuiz package to run
quake1 at this point, so I would say that is grounds to include
darkplaces as a separate package.
* contains? provides? produces? who knows...
Cheers Simon,
David
Reply to: