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

Quake packaging [Re: Debian Games Team Policy]

Hey all - hijacking this thread... ;)

Packaging for quakespasm is in a fairly OK state (well, it's the same as
it was a few months ago), so I'm wondering what's the best way to
progress?  I'm not fussed about the precise arrangement of packages and
prefer to leave that to those who know better, but I'll gladly implement
it in the package.

On 16/05/11 17:49, Simon McVittie wrote:
 > - starting point: quake [contrib] (includes an engine) Depends:
> - upload the engine (darkplaces or whatever) as a separate package
> - change quake to have a Depends on darkplaces (or darkplaces|quake-engine)
>   and only contain "launcher" stuff for Quake 1
> - upload openquartz, which (packaging-wise) looks a lot like quake

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'?

> Another option would be to pre-empt that by having the quake contrib package
> never contain the engine at all, and packaging the engine separately from the
> start. Still not a whole lot of point playing with virtual packages
> until/unless we have two useful engines, though.

Well, that seems more sensible to me, but I think I have probably missed
some kind of practical consideration above.

I have recently made a tiny tweak to the quakespasm packaging to Provide
quake-engine and Depend on quake-data, after installing my data using
game-data-packager.  What would be the best place to go from here?  I
see three ways to go:

1.  Make the quakespasm package usable immediately by adding a launcher
script to the package.  I don't see any real problem with this as the
user would expect the package to work 'out of the box' in any case, and
the launcher script would just use /usr/bin/quakespasm so it would not
conflict with any /usr/bin/quake that we provided later.

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

3.  Set about packaging another engine to settle the above questions
over what kind of package structure to use.  I would probably choose
Proquake, though it has a slightly yucky source structure, or maybe we
could adapt Nexuiz (I need to look into this).

I think the best option is #1, but that might be down to personal
laziness ;)  I have no idea if #2 makes any sense or not.  Really I just
want to know what's the next thing I can do to help, but hopefully some
of the above will clear up some of my misconceptions as well.


Reply to: