Hi folks,
I wanted to write a message to summarise the progress made
on doom packaging between etch and lenny, and to lay out
some of my plans for squeeze. Please feel free to comment
on any part of this, but I'd suggest changing the subject
to something contextual as this email is a bit big.
Contents (for ease of searching)
1. What's new in Lenny
2. Review of Debian patches
2.1. prboom
2.2. freedoom
2.3. deutex
3. What's next for squeeze
3.1. new packages
3.2. BSP/nodes builders
3.3. doom packaging guidelines
1. What's new in Lenny
----------------------
We completed a few packaging transitions in the etch-lenny
cycle, including the introduction of "boom-wad" which paves
the way for packaging chocolate-doom. The freedoom package
grew another binary, "freedm", a multiplayer-oriented game.
"doom-package" included in etch grew into the much more
sophisticated and more generic "game-data-packager". This
supports a plethora of doom-related games: doom, doom2 and
the two halves of final doom. Although the package is still
only useful for doom, the groundwork has been put in to
support other split data/engine schemes (such as the quake
family).
2. Review of Debian patches
---------------------------
Here follows a list of patches we carry for upstream doom
packages, what they do, and what their future is. (I
encourage anyone carrying lots of upstream deviations to do
the same from time to time!)
2.1. prboom
-----------
do_not_rebuild_prboom.wad.patch
this disables the rebuilding of prboom.wad, a resource
file. As part of adjusing prboom upstream to be DFSG
compliant, we modify the supplied (prebuilt) resource
file in the source package. There's no need to rebuild
it (which would mean adding a build-dep on deutex, at
least) so we don't, using this patch.
We are likely to carry this patch as long as we modify
upstream source to create a dfsg-compatible
orig.tar.gz. That might not always be necessary: the
components of the resource file which are non-free
might be fixed upstream. They are certainly keen,
it's just not easy to do it nicely.
explain_no_iwad.patch
we make an informational message more informational.
The upstream message simply says "IWAD not found" if
there is no game data present. This patch explains
where to find game data. It's fairly Debian-specific,
and imho necessary since we moved the doom-wad
dependency to Recommends:.
readme_customization.patch
Some minor customisation of the documentation. We
remove reference to an upstream file that we don't
provide in the binary package, and add references to
the man pages.
I think this would make more sense upstream, and will
ask them.
windowed_mode.patch
We change the default display mode to windowed, from
fullscreen. This is to avoid exposing people to some X
bugs that can occur when we try to set the X
resolution to a very small number (doom's default
resolution is 320x200 which is not even 4:3). Some
drivers support such modes, many monitors do not.
This patch may not go away but might evolve and be
partially incorporated upstream if we ever come up
with a cross-game consensus on how to handle user
preferences for full screen vs. windowed mode.
I will raise the issue of fullscreen vs. windowed
mode on the newly created cross-distro games list.
2.2. freedoom
-------------
makefile.patch
this hardcodes a path to a binary (deutex). In some
build environments, /usr/games is missing from $PATH, so
it cannot be relied upon. However, we modify deutex
to install to /usr/games (it defaults to /usr/bin) so
this patch is unlikely to make it upstream. One which
ensures that /usr/games is in $PATH might however. I
will look into that.
2.3. deutex
-----------
destdir_hack.patch
Adjusts build scripts to install the binary into
/usr/games and adds support for a DESTDIR prefix
which allows the debian build process to "install"
the package into debian/deutex, ready for stuffing
into a .deb.
This is necessary because upstream abhor autotools
and are unlikely to change that.
iwad_search_path.patch
deutex requires an IWAD for many operations it
performs. Normally it only checks the current working
directory for one. This patch makes it check in
/usr/share/games/doom too, which is where the Debian
packages put them.
There's a chance this would be accepted upstream,
although the hardcoded UNIX path might not be
suitable. I will ask.
logging_segv.patch
This fixes a segfault caused by a bad pointer. This
has been applied upstream but a new release is not
forthcoming.
manpage_charset.patch
Upstream use non-ASCII chars in their manpages. They
are aware of this issue, but I might ask whether
they'd accept this patch anyway, which approximates
the required accent using roff-legal methods.
3. What's next for squeeze
--------------------------
3.1. new packages
-----------------
I want to introduce a few more engines. On the cards are
chocolate-doom, prboom-plus and remood.
We do not have a level editor. Yadex used to be packaged
but was orphaned and removed. Yadex lives on but is a
fairly old-style UNIX program. I think Darren Salt might
maintain it externally. Asides from that, I would like
to package up "wadc", a fairly unique program which lets
you build levels from scripts. I contacted the upstream
author (Wouter van Oortmersen, you may remember him as
the author of cube and sauerbraten) and he has given me
permission to assume the role of upstream for any
future changes to the program.
I think that Debian would benefit from a launcher
program. Such a program allows you to tailor the exact
settings for a given game of Doom: starting level,
additional maps to use; difficulty; which engine and
world resources, I think that a launcher program, to
help users customize a specific game; etc. I do not know
of a suitable candidate program (there were loads of
them in the DOS days) so I might have to coordinate
developing one upstream.
3.2. BSP/nodes builders
-----------------------
One component of level editing is a binary space
partition (or nodes) builder. I began packaging one of
them (called 'bsp') but abandoned that after Darren Salt
had glbsp uploaded (which is a superset of the bsp
features).
glbsp also builds additional helper information for
ports which use OpenGL rendering. Prboom, already
packaged, has an OpenGL renderer, and can apparently
benefit from gl nodes. I am going to investigate
building gl nodes for the freedoom IWAD.
3.3. doom packaging guidelines
------------------------------
I have a bug against debian-policy queued up to submit
after this mail to include the virtual package names
recommended in the doom packaging guidelines into the
canonical list maintained within policy.
I am unsure whether or not to submit the doom packaging
guidelines to debian policy. There is no clear precedent
(perl packaging appears to be policy, whereas java
packaging is recommendation). I may seek advice on
the debian-policy mailing list.
If we are not to merge the guidelines into the main
policy package, I am considering converting the doom
packaging guidelines into a separate package. Then, a
given stable release of Debian would have packaging
guidelines within it which corresponded to what was
convention at the time of release, for whatever value
that would be. It would make maintaining the guidelines
easier. Precedent includes debian-policy, maint-guide,
debian-reference and lua5.1-policy.
I am interested in working on the packaging of quake
1/2/3 games in Debian. I think such games would benefit
from a similar set of guidelines for inter-operation
(virtual package names, file layouts, menu sections,
etc.). It might be worthwhile to follow the doom-package
evolution and evolve the doom packaging guidelines into
game packaging guidelines. This would definitely make
sense if we ended up packaging the guidelines.
If we did that, there might be several other packaging
conventions that we use that could find a home in such
a document/package.
--
Jon Dowland
http://jmtd.net/
Attachment:
signature.asc
Description: Digital signature