[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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"


Reply to: