Bug#811133: game-data-packager: z_code.py produces packages which only support the engine installed at build-time

[Simon McVittie]

On 15/01/16 23:46, Alexandre Detiste wrote:
> It would be better to have an updatable runtime shipped in
> a game-data-packager .deb or a runtime-only spun-out deb
> than to have z_code generate a 2-line shell script that can't be
> updated without requesting user to recreate the .deb with GDP.

Yes. This is why doom2-masterlevels' launcher is in
game-data-packager.deb, and why my current work in progress on a
general-purpose launcher for non-free games with behaviour that can be
modelled declaratively (currently Unreal and UT99) is in that .deb too.

[Stephen wrote]
>> Ideally the package
>> should use the zcode-interpreter alternative, although that isn't
>> supported by all packages Z-Machine emulators currently, and doesn't
>> work well with X- v. terminal-based interpreters.

I suspect this may mean that the zcode-interpreter alternative isn't
very well designed, and it should either be a pair of alternatives
zcode-interpreter and x-zcode-interpreter (like www-browser and
x-www-browser), or just assume that in practice anyone running via the
alternative is a graphical environment (and so use a script that wraps
frotz in x-terminal-emulator if necessary).

I think alternatives should always be thought of as an "API": when I run
any implementation of the alternative, in a specified environment (for
instance "in X"), with a specified set of command-line options (perhaps
none), it does a particular desirable thing (like "plays Quake"). For
instance, see /usr/share/doc/quake*/policy.txt for what it means to
implement quake[2]-engine[-server]. Not every alternative actually needs
a mini-policy like that, but it should always be possible to write one,
and actually writing one might be a good way to focus your thoughts.

    S