game-package and handling locally built .debs

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


-- 
To UNSUBSCRIBE, email to debian-devel-games-requestlists.debian.org
with a subject of "unsubscribe". Trouble? Contact
listmasterlists.debian.org

Hi,

Am Mittwoch, 9. Januar 2008 16:42 schrieb Jon Dowland:
[..]
> Could the .desktop file be shipped referencing
> /usr/games/doom and have the menu entry not appear in
menus
> unless the target existed? 

This seams possible with the TryExec field [1]. Haven't
tried this myself yet 
though.

Cheers,
    Stefan.
-
[1]: http://standards.freedesktop.org/desktop-
entry-spec/latest/ar01s05.html

On 1/9/08, Jon Dowland <listsalcopop.org> wrote:
> 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?

Use the gdebi package, it provides both a GUI and CLI that
install
.deb files with dependencies.


-- 
To UNSUBSCRIBE, email to debian-devel-games-requestlists.debian.org
with a subject of "unsubscribe". Trouble? Contact
listmasterlists.debian.org

On Wed, Jan 09, 2008 at 05:08:10PM +0100, Stefan Potyra
wrote:
> This seams possible with the TryExec field [1].
Haven't
> tried this myself yet though.

Thanks, that sounds like what I need. I had a quick play
and
gnome-panel (at least) didn't seem to like symlinks for the
target, but I haven't looked in much depth yet.


-- 
Jon Dowland


-- 
To UNSUBSCRIBE, email to debian-devel-games-requestlists.debian.org
with a subject of "unsubscribe". Trouble? Contact
listmasterlists.debian.org

On Jan 9, 2008 10:42 AM, Jon Dowland <listsalcopop.org> wrote:
> 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)?

It sounds better to write a wrapper script that tests for
these
conditions and executes doom if all tests were true.
Something like.

   [ -x doom ] || xmessage "helpful message"
   # Continue if doom was executable
   doom

This way, a desktop and/or menu entry can use the wrapper
script, and
you can avoid having to do some complex stuff with the
desktop
entries. For the disk space problem, try df.

By the way, I'm curious to know what the problem is with
using root to
run wget and the patching.

-- 
Regards,
Andres Mejia


-- 
To UNSUBSCRIBE, email to debian-devel-games-requestlists.debian.org
with a subject of "unsubscribe". Trouble? Contact
listmasterlists.debian.org

  Hello,

On Jan 11, 2008 5:37 AM, Andres Mejia <mcitadelgmail.com> wrote:
> By the way, I'm curious to know what the problem is
with using root to
> run wget and the patching.

  The less code you run as root, the less potential security
problems.
Never use root for more than you absolutely should.

  Cheers,

      Vincent


-- 
To UNSUBSCRIBE, email to debian-devel-games-requestlists.debian.org
with a subject of "unsubscribe". Trouble? Contact
listmasterlists.debian.org

On 1/10/08, Andres Mejia <mcitadelgmail.com> wrote:
> It sounds better to write a wrapper script that tests
for these
> conditions and executes doom if all tests were true.
Something like.
>
>    [ -x doom ] || xmessage "helpful message"
>    # Continue if doom was executable
>    doom
>
> This way, a desktop and/or menu entry can use the
wrapper script, and
> you can avoid having to do some complex stuff with the
desktop
> entries.

What is more complex, a single line in the desktop file, or
an extra
wrapper script?

In any case, this is moot, because if the data packages
depend on some
(virtual?) package providing an engine executable, then the
desktop
entries can just assume the presence of the executable.


-- 
To UNSUBSCRIBE, email to debian-devel-games-requestlists.debian.org
with a subject of "unsubscribe". Trouble? Contact
listmasterlists.debian.org