some review of pending g-d-p changes

Sun Apr 26 23:59:16 UTC 2015

Thanks for review.

Le dimanche 26 avril 2015 21:48:36, vous avez écrit :
> arx
> ===
> 
> Can we put the various demo and different language versions in
> /usr/share/games/arx-demo-en (etc.) and make the engine search by
> language, or use alternatives, or something? As an engine maintainer I
> really prefer to be able to install several datasets in parallel and use
> "quake --demo" etc., rather than having to install and uninstall
> different versions.

As previously said, I agree, but the package maintainers must agree too to make the change
on their side first. The yaml files are merely reflecting the actual situation.
(and most package-specific Arch & Gentoo package scripts suffer from this
non-co-installabalilty too)

Problem is that Arx Libertatis - while actively maintained - comes from an unofficial repository:
http://software.opensuse.org/download/package?project=home%3Adscharrer&package=arx-libertatis

So for most users, they set it up in 3 minutes and then forget about it;
and no-one never feels the need to file an ITP for it :-(

It would be hard to enforce such policy on upstream.

I advocate upstreams to at least search for data in a FHS-compliant folder,
(/usr/share/games/<original game name>) 
saying that it would also benefits users of other distros... and most agrees to the changes:
https://bitbucket.org/opentyrian/opentyrian/commits/84f88079d83deedab973a8664466ba07ea10582e

Some other games mix their bits with the one from game data:
dpkg -S /usr/share/games/openttd/
transport-tycoon-deluxe-data, openttd-data, transport-tycoon-deluxe-music: /usr/share/games/openttd

If they process all the files at ones with a glob() or something, this can make sense;
and this would get hard to split out (link farms ?)

> duke3d
> ======
> 
> Same as arx

Duke3d will never be in Debian... unless someone makes Ken Silverman
change his mind about this:

BUILD SOURCE CODE LICENSE TERMS:                             06/20/2000
[1] I give you permission to make modifications to my Build source and
       distribute it, BUT:
[2] Any derivative works based on my Build source may be distributed ONLY
       through the INTERNET.
[3] Distribution of any derivative works MUST be done completely FREE of
       charge - no commercial exploitation whatsoever.
...

> 
> doom2-masterlevels
> ==================
> 
> I'm very tempted to just ship this in g-d-p for now, and do the
> NEW-queue round-trip later.

Do you fear the doom2-masterleves .deb would hold back the gdp.deb ?
I have seen other packages starting to spin out a -dev or a -dbg,
and this had to wait in NEW, while the original package was already
in testing. Or am I misunderstood ?

> If we're going to need a trip through the NEW queue *anyway*, I wonder
> whether a game-data-packager-support package might be better: we could
> use that for any similar things we need subsequently.

This can also means shipping the changelog.gz in this package and symlink
all generated .deb to this ?

> We could put a dummy executable file in doom2-masterlevels-wad and refer
> to it in TryExec in the .desktop file for the frontend, like we do for
> Quake III Team Arena (look in src:quake3)?

Would a symlink to /bin/true work ?
This way we don't even need to ship a dummy .sh

> 1020x800 seems large, and won't fit on my 1366x768 laptop (which is a
> common size for ultraportables, and pre-HDTV LCD panels in general). Can
> it fit in 800x600 or smaller?

I can be reduced to 1000x600 easily.
I have a Eee PC 701 at hand to try it on (800×480),
I need to dig deeper on how this text size/dpi stuff works.

> (I don't have these wads myself, so I
> haven't tried the launcher so far, but perhaps I can fake it for testing
> via symlinks to some wad with at least the same number of levels.)

I test it by adding an 'echo' at the being of the subprocess call.
I'm tempted to show the command to-be-run in a read-only text box.

> 
> dreamweb
> ========
> 
> > +  dreamweb-us-data:
> > +  dreamweb-uk-data:

That's just a 1:1 mapping with the zip files.

> I'd prefer -en-us-data and -en-gb-data (or whichever of them is the
> preferred version upstream could be -en-data) - uk is the ISO 639-1
> language code for Ukrainian, which is not what's in that package :-)

http://www.the-adventuress.com/2012/10/dreamweb-is-now-freeware-at-scummvmorg.html

This blog says:
 | "The versions available from ScummVM include both English versions
 | (the uncensored UK version and the censored North American version)",
 | so the uk/us versions have nothing to do with color/colour grammar
 | or re-recorded speech.

So maybe dreamweb-en-censored-data & dreamweb-en-data ?
Which would be the default ?

> 
> consider_zip
> ============
> 
> filenames would be better called try_to_unpack or something - calling it
> "filenames" doesn't really disambiguate.

Ok,
I just tried to keep this changeset minimal.

> 
> various unpacking mechanisms
> ============================
> 
> Can unace, cabextract, unrar specify files to unpack? I prefer to unpack
> a list of specified files when we can, rather than the whole thing.

cabextract certainly not (and there were only one file in each .cab),
I'll have a look again at unrar & unace.

> 
> make_template
> =============
> 
> sums['ck'][name] really ought to be a tuple (cksum, size), or (None,
> size) if the CRC32 is not known.
> 

? 
do you really want to add this kind of stuff with rainbow tables to compute a cksum in python:
http://stackoverflow.com/questions/6835381/python-equivalent-of-unix-cksum-function,
ok subprocess(cksum).

If not why keeping alle these fixed 'None' values ?

> util
> ====
> 
> If we prefer en_GB (or en_US for that matter), we should put en next in
> the preference order automatically - my British English GNOME setup sets
> LANG=en_GB.utf8 but does not set LANGUAGE

Ok fixed now.

This doesn't pretend to implement complete decoding of all possible values of LANG,
like systemd: http://cgit.freedesktop.org/systemd/systemd/tree/src/locale/language-fallback-map;
only what is seen in actual commercial games.

> I'd certainly prefer to play adventure games in en (i.e. probably _US) than
> any other language :-) 

Partially Implemented:
http://anonscm.debian.org/cgit/pkg-games/game-data-packager.git/commit/?id=c16105911edb419b6525e297ce0b6f78c955633e

This needs a little bit more polish, lang override should be possible with "--package" too
(now only LANGUAGE=xx ./run ... ).

----

For now, all games are avaible only in english;
but I planned this feature for "Flight of the Amazon Queen".

The package in Debian is only the english version;
I would package the french/german/hebrew/italian versions with GDP.
http://scummvm.org/games/#queen

GDP will need to show the help_text pointing to the package in the official archive
when run with LANG=en

This would be for a next release.

> Probably the same for pt_BR, although AIUI
> Brazilian Portugese and Portugese Portugese differ a lot more than
> British and American English.

I guess they are used to deal with this anyway.
(like when I get stuff in dutch online when I would prefer in english)

Use of LANGUAGE is now hinted in GDP man page.
(GDP_MIRROR & DEBUG not)

Alexandre

-------------- next part --------------
A non-text attachment was scrubbed...
Name: startup.png
Type: image/png
Size: 106702 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-games-devel/attachments/20150427/74cf3da8/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: master-levels-for-doom-ii-01.jpg
Type: image/jpeg
Size: 46852 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-games-devel/attachments/20150427/74cf3da8/attachment-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: minimal1.png
Type: image/png
Size: 100387 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-games-devel/attachments/20150427/74cf3da8/attachment-0003.png>