Bug#1059449: game-data-packager: Fate of Atlantis fails to start without "scumm:" prefix

[Mathias Gibbens]

Package: game-data-packager
Version: 76
Severity: normal

After building and installing the package for Indiana Jones and the
Fate of Atlantis, it fails to start because scummvm now knows about two
"atlantis" games: "scumm:atlantis" and "cryomni3d:atlantis". Without
the "scumm:" prefix in the Exec statement of the generated .desktop
file, nothing happens when trying to launch the game.

> --- a/fate-of-atlantis-en-data.desktop 2023-12-25 20:44:49.888531966 +000
0
> +++ b/fate-of-atlantis-en-data.desktop 2023-12-25 20:44:46.200557922 +000
0
> @@ -6,4 +6,4 @@
> Terminal=false
> Type=Application
> Categories=Game;AdventureGame;
> -Exec=scummvm -p /usr/share/games/fate-of-atlantis-en atlantis
> +Exec=scummvm -p /usr/share/games/fate-of-atlantis-en scumm:atlantis

[Alexandre Detiste]

Hi,

I have briefly discussed the situation of the Scummvm plugin
with Simon last month in Cambridge.

We agreed that there is too much intelligence in the generated, "unfixable"
(unless someone takes the time to repack the game), generated .deb's;
and that some or most of this intelligence should be moved
to automatically upgradable game-data-packager-runtime.

So actually (option a) the .desktop file would looks like this:
> > +Exec=/usr/share/games/game-data-packager[runtime] fate-of-atlantis-en-data

_or_ (option b) game-data-packager-runtime would ship .desktop files
pre-generated for each game but that would mean spamming
the various desktop environments with so many TryExec=
and I don't know if they would cope

I prefer option a.

I'm getting back at this in 2024

Greetings

[Alexandre Detiste]

Le mar. 16 janv. 2024 à 09:57, Sébastien Noel <seba...@twolife.be> a écrit :
> > I prefer option a.
>
> option 'a' would implies that g-d-p-runtime has access to g-d-p data to
> make the magic happen; a dependency we don't currently have

That could be an extra, tiny, scummvm.json generated at build time
with the absolute minimal required infos:
the mapping from package name to scummvm-id-of-the-day,
+ ... ?

[Simon McVittie]

On Wed, 27 Dec 2023 at 14:18:25 +0100, Alexandre Detiste wrote:
> We agreed that there is too much intelligence in the generated, "unfixable"
> (unless someone takes the time to repack the game), generated .deb's;
> and that some or most of this intelligence should be moved
> to automatically upgradable game-data-packager-runtime.

The more often I see bugs in our generated .deb that cannot be fixed
without regenerating and reinstalling the .deb, which we could have
fixed in a new upload if it was structured differently, the more sure
I am that this is the way we should be going.

As a design principle, we should be trying to make sure that each generated
.deb only contains:

- files that we cannot legally redistribute
- an absolute minimum of "glue" which is so simple that it cannot have bugs
(for example a symlink to an executable, icon or .desktop file provided
by g-d-p-runtime is usually better than shipping an executable, icon
or .desktop file in the generated .deb itself)

> So actually (option a) the .desktop file would looks like this:
> > > +Exec=/usr/share/games/game-data-packager[runtime] fate-of-atlantis-en-data

The .desktop file, itself, is something that can have bugs (for example
missing Keywords, or referencing an icon that no longer exists), and
there is no legal or technical reason why we can't write .desktop files
that are Free Software and put them in game-data-packager-runtime, which
would let us fix their bugs whenever we want to by uploading a new version
of g-d-p. So we might as well do that!

> [option c proposal]
> pre-generated .desktop files shipped in game-data-packager-runtime at a
> unusual place & a symlink in the generated .deb's to activate it

Yes, this is the way.

We already generate ut99.deb containing a symlink
/usr/share/applications/ut99.desktop -> ../games/game-data-packager-runtime/ut99.desktop
pointing to a .desktop file that we can change as much as we want to.
More of this, please!

I see that Sébastien has been contributing launcher glue for old
binary-only Loki games like Railroad Tycoon 2, and this seems a completely
reasonable way to handle such games.

But, having said that:

> option 'a' would implies that g-d-p-runtime has access to g-d-p data to
> make the magic happen; a dependency we don't currently have

Whenever we find a situation where we want this, we can ship a
subset of g-d-p data in g-d-p-runtime. We effectively already
*do* ship a subset of g-d-p data in g-d-p-runtime: the files
/usr/share/games/game-data-packager-runtime/launch-*.json contain inputs
for the gdp-launcher multi-engine launcher.

As an implementation choice, we've separated the data for g-d-p
(data/ut99.yaml) from the data for the launcher (data/launch-ut99.yaml.in),
but we can restructure that any time we want to - the exact division
between those two is private to the game-data-packager source package, and
does not form part of a stable API.

(For scummvm, where all the games follow a common pattern and have
more similarities than differences, it would perhaps be better to
have a dedicated scummvm launcher rather than reusing the multi-engine
gdp-launcher program, but either is fine.)

The closest thing to a stable API here is that iortcw and openjk rely on
the existence of /usr/share/games/game-data-packager-runtime/gdp-launcher,
and the fact that when run as "openjk_sp" or similar, it knows how to look
up what game to launch.

> That could be an extra, tiny, scummvm.json generated at build time
> with the absolute minimal required infos:
> the mapping from package name to scummvm-id-of-the-day,
> + ... ?

Yes, this.

smcv

[Alexandre Detiste]

Hi,

There are potentially other games affected by the exact same ScummVM change.

I will check a few I have.

Manhole is interresting

$ scummvm --list-all-games | grep manhole
director:manhole The Manhole
made:manhole The Manhole

> After building and installing the package for Indiana Jones and the
>Fate of Atlantis, it fails to start because scummvm now knows about two
>"atlantis" games: "scumm:atlantis" and "cryomni3d:atlantis". Without
>the "scumm:" prefix in the Exec statement of the generated .desktop
>file, nothing happens when trying to launch the game.
>
>> --- a/fate-of-atlantis-en-data.desktop 2023-12-25 20:44:49.888531966 +0000
>> +++ b/fate-of-atlantis-en-data.desktop 2023-12-25 20:44:46.200557922 +0000

>> -Exec=scummvm -p /usr/share/games/fate-of-atlantis-en atlantis
>> +Exec=scummvm -p /usr/share/games/fate-of-atlantis-en scumm:atlantis

git/game-data-packager $ out/run-tool-uninstalled tools/check_scummvm_ids.py
discarding non-discriminating id: martian
discarding non-discriminating id: overtheedge
discarding non-discriminating id: atlantis -> of course
discarding non-discriminating id: wingman
discarding non-discriminating id: circus

{'dw2-gb', 'manhole', 'gob2cd', 'rosetattoo-es', 'os-us', 'znemesis',
'jones-fast-lane', 'littlered', 'zgi-win', 'monkey-it', 'lol-fr',
'tucker-fr', 'lab-win', 'manhole-cd', 'lit2-win-fr', 'sherlock-logo-1',
'puzzle', 'goldrush', 'monkey-de', 'sword2demo', 'os-fr', 'gob', 'rtz-cd',
'hires1-apple2', 'fairytales', 'troll', 'sherlock-logo-2',
'gob1-demo-fr', 'lgop2-fr', 'monkey-fr'}