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

Re: Bug#689824: RFP: yquake2 -- Yamagi Quake II - Enhanced client for Quake II

On 03/10/13 14:50, Jonathan Dowland wrote:
> I also plan(ned) to write down the quake scheme in the
> doom-packaging¹ guidelines

src:quake has debian/policy.txt (installed to
/usr/share/doc/quake/policy.txt) which describes how it works. Patches,
clarifications, changes welcome :-)

Please refer to the version in git master / the NEW queue, which
includes Quake II support. I'm probably going to fold src:quake3 into
src:quake at some point too, since it's pretty similar (they've had bugs
in common in the past), and the merged package will still be practically
instantaneous to upload.

In my Quake II packaging, the quake2 script automatically uses the
commercial data if you have it, or the demo if you don't (or if you pass
--demo) - they're co-installable and use different top directories. I
think that's a good way to deal with shareware vs. retail data. In the
quake2-server package, I even took advantage of the different top
directories to have demo and full-game servers default to different
config files and hence different starting maps :-)

> raise for discussion whether it's worth having that as an actual
> package, or as a sub-policy of debian-policy

What do we gain by formalizing this into Policy? I think a mini-policy
is plenty - particularly if each game has an obvious "central package"
(the one with the wrapper script, .desktop etc.) where it can go.

My assumption had been that a bunch of engines maintained by a small set
of people in pkg-games are an example of the "cooperating group of
packages" exception in Policy §3.6. It's not as if we're talking about
x-terminal-emulator or anything like that :-)


Reply to: