game-package and handling locally built .debs

[Jon Dowland <lists@alcopop.org>]

Hello there,

I've been spending some time working on "game-package", a
tool to build .deb files of non-free content that can be
used in conjunction with things in contrib. For example, to
create "doom2-data" debs that satisfy doom-engine and can
allow the installation of prboom.

The current model for this tool is you run the tool as a
non-priviledged user to generate a .deb file containing the
data in question, which you can install however you like.

This is in contrast to e.g. flashplugin-nonfree, or the old
quake2-data, which are run at installation time as root, and
suffer from several edge-cases which can result in the
package beinge installed but the data not being present (and
having Installed-Size not be accurate, etc.), and run a lot
of code priviledged that really needn't be (wget and other
fetch tools, cabextract, some patching stuff) and abuse
debconf prompts.

I have ended up in a situation where I would like to
generate .deb files which have dependencies that might not
currently be satisfied. 

Specifically, I'd like generated doom2-data .deb files to
Depend: on a doom-engine, contain a .desktop file which
calls /usr/games/doom, anad for doom-engine providing
packages to install an alternative for /usr/games/doom.

That way, we will have menu entries which reflect the game
being played, rather than the engine (so "Doom 2",
"Freedoom"; rather than "prboom", "chocolate-doom") and we
can have icons for the menu items which are derived from the
copyright data (at .deb-build time).

The problem with this is that at present, you would do
something like

	<find your doom2 cd>
	game-package doom2 /media/cdrom/doom2cd/doom2.wad
	sudo dpkg -i ./doom2-data*deb

That last step will fail if the .deb depends on packages not
currently installed.

I have tried to think of a solution and I think I have
two, in increasing order of difficulty:

        a)

           the doom2-data package could include a fake_doom
           script and install that as a low-priority
           alternative for /usr/games/doom. That way, they
           could still dpkg -i the generated .deb, it would
           not depend on a doom-engine, and if they tried to
           use the menu entries before installing an engine,
           the fake_doom script could use whiptail, or
           zenity, or xmessage, etc. to display an
           informative message to the user "install an
           engine package".

           We would need one of zenity / xmessage / whiptail
           + an x terminal emulator installed, which I think
           is highly likely, and we could put *that* part of
           the dependency into the Depends: field for
           game-package, which would be typically installed
           via apt tools.

       b)

           This is what I think is the "proper" solution,
           but it is not easy.

           A separate package is created which facilitates
           maintaining a local package repository. It
           creates the repository layout, adds it as a
           source for apt, and provides a set of shell
           helper scripts to insert .debs into it, and
           remove packages from it.

	   I've looked at a few existing packages that do
	   this sort-of thing (reprepo etc.) but none of
	   them seem to be user-friendly enough at present
	   for this use-case. Improving them or building on
	   them might be an option.

           the game-package script could then inject the
           generated .deb straight into this local package
           repository

           The advantage of this approach is: we don't run
           patching, wgets, etc. as root; we do not have
           corner-cases where you can install the engine
           without data, or vice-versa; we do not burden the
           user with too many commands to get the stuff
           setup.

           The disadvantage would be disk space usage.
           Imagine quake2-data package existing in the local
           repository, in /var/cache/apt, and unpacked in
           the filesystem. There *might* be solutions to
           this, too.

Really, this is a more general problem of how can you handle
individual .deb files in a way which leverages the
dependency-tracking stuff in apt/aptitude?

My question to the team is really, are there some other nice
solutions? Could the .desktop file be shipped referencing
/usr/games/doom and have the menu entry not appear in menus
unless the target existed? Could we manage
installing/removing .desktop/menu entries using dpkg
"hooks"; and only have them present when both an engine
_and_ a data package were present? How might we overcome the
disk-space issue in the case outlined above? Exactly how
undesirable is the fake_doom "hack" outlined in a)?



-- 
Jon Dowland