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

Re: plans for doom packages

On Fri, Jun 28, 2013 at 10:53:13AM +0100, Simon McVittie wrote:
> On 28/06/13 09:42, Jonathan Dowland wrote:
> > deng does not accept the same command-line options as doom.exe did, so I don't
> > think it should provide /usr/games/doom (or doom2) as an alternative.
> Is the exact meaning of /usr/games/doom documented anywhere? For Quake,
> /usr/share/doc/quake/policy.txt in the quake package describes what
> quake-engine and quake-engine-server mean; it excludes options other
> than -dedicated, -basedir, -hipnotic and -rogue.

No, it isn't: the prospect of commandline-incompatible engines did not occur
to me when I wrote <http://pkg-games.alioth.debian.org/doom-packaging/>,
which is otherwise where I suppose it should go, although I did hope to
package that so the guidelines existed in the archive (they seriously
lack exposure).

> If necessary you could have a deng-doom script which translates a subset
> of doom.exe command-line parameters to deng syntax, like
> /usr/bin/gnome-terminal.wrapper does for gnome-terminal? (gnome-terminal
> is not a valid x-terminal-emulator alternative, due to incompatible
> command-line syntax, but gnome-terminal.wrapper is.)

Fabian worked on something like that, I think it is actually in the package
now (<http://bugs.debian.org/691741>) but I don't think the maintainer
(Gustavo) was happy with that solution (http://bugs.debian.org/693206#40>).
However I haven't managed to keep up with the discussion so I don't know
what people's opinions are now.

Personally I'd like the virtual packages defined as being compatible with a
subset of DOOM/DOOM2.EXE command line arguments, syntactically and
semantically, which I think is the current status quo with Fabian's vavoom
wrapper (and thus something similar would be needed for deng for it to
provide: doom-engine.)  I'd like to see this codified in either doom-packaging
(and that turned into a package, and perhaps expanded to include e.g. the
quake packaging conventions, and renamed game-packaging-guidelines), and/or
extend debian-policy's registry of virtual package to define semantics for
all virtual packages (much more work but potentially more valuable). However
I'd be open to the way the doom packages interrelate being reworked, and I
seem to recall you suggesting this, along the lines of the quake ones, I
just lack the time to reason it all out! ☺

Jonathan Dowland

Reply to: