Re: Quake packaging [Re: Debian Games Team Policy]
On Wed, 25 May 2011 at 15:18:40 +0100, David Banks wrote:
> I'll take a stab at understanding you here Simon, though I am not sure:
> you are proposing to upload the engine + launcher script under the
> initial name 'quake', then when multiple engines become available we
> would move the engine out of the 'quake' package and into a package
> named 'darkplaces', 'quakespasm', or whatever, and leave only the
> launcher script in the 'quake' package, plus a dependency on 'quake-engine'?
Yes; that's close to what happened to Quake 3 (the engine is ioquake3).
> 2. Create a separate quake package with a generic launcher script that
> depends on quake-engine. Quakespasm can then use alternatives (?) to
> install itself as /usr/bin/quake-engine. So the 'quake' script takes
> care of various environment setup stuff and providing a nice
> command-line UI, and each Quake engine package can use either its
> vanilla binary (if it acts sanely and uses the quake-data location) or a
> very simple shell wrapper (like Quakespasm would probably do) to provide
This sounds good, although I'd be inclined to have quakespasm just contain the
actual binary, and do the environment setup / shell wrapper / predefined
command-line options (to make it use the quake-data location) in the launcher
script in the quake package.
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.
(Analogously: quake3 and openarena each contain the environment setup for
their respective game in a wrapper script; ioquake3 is just the actual
engine, which isn't even in the $PATH.)
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
* 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"