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
> /usr/bin/quake-engine.
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"
Regards,
S
Reply to: