some review of pending g-d-p changes

[Simon McVittie]

On 27/04/15 00:59, Alexandre Detiste wrote:
> 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)

Fair enough.

> 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.

That might be OK for non-free, actually. AIUI, people who put a subset
of non-free on CDs are expected to do their own license-compliance:
Debian does not guarantee that everything in non-free is distributable
by others, only that it is distributable by our mirror network.
(I'm unlikely to maintain it, though.)

>> 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 ?

Yes. New binary packages (.deb) go back through NEW, and nothing from
the same source-package upload will reach experimental/unstable/testing
until the new upload has been checked.

This does not mean new binary packages are always bad, but it does mean
that they have somewhat a higher overhead than other types of package
change, and it's good to get them right first time.

>> 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 ?

Possibly; I was more thinking of things like the ability to ship the
Cacodemon icon in g-d-p-support rather than copying it repeatedly.

Duplicating the changelog is actually good in a way, since it means that
every .deb has *its own* changelog, rather than the changelog from a
potentially different version of g-d-p. I don't think we want to give
game data packages a lockstep dependency on
game-data-packager-support (= ${source:Version}).

We'd probably want to weaken the dependency on python3-gi and the Gtk
gir stuff to a Recommends or even Suggests if the doom2 launcher was
just part of a larger package, since they're only desirable if you
*also* have doom2-masterlevels-wad.

Alternatively, perhaps the generated packages should just hard-depend on
game-data-packager (which in practice you will probably keep installed
anyway)... and g-d-p is going to gain a Recommends on Gtk3 bits as soon
as we do a GUI for it (or perhaps sooner and at Depends level, since I'm
very tempted to depend on python3-gi for the necessary internal
refactoring to make it asynchronous and hence GUI-friendly).

>> 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

Yes, or a symlink to /etc/alternatives/doom would be even better. That
way the TryExec would fail unless we had both doom2-masterlevels-wad and
a doom-engine implementation, which is exactly what is desired here.

> 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 ?

If the difference is level of censorship rather than color/colour etc.,
then yes, -en-censored- and -en- seem like better names. I would
personally make -en- the default, unless the uncensored version is
particularly gratuitous (I don't know the context here).

>> 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 ?

I don't want a data structure called cksums (or equivalent) that does
not (at least conceptually) contain the checksums for which the data
structure is named :-)

Perhaps this is a sign that we should have

sizes:
    666 doom.wad

rather than mimicking cksum format, at least in make-template. I only
used cksum initially because it was a convenient way to gather exact
byte-sizes at the command line, without picking up a bunch of irrelevant
information like `ls -l` would; it's a lot more convenient to be able to
tell bug reporters "please run cksum, md5sum and sha1sum on your version
of Quake" than it would be to give them a ls | awk incantation.

I suspect that cksum uses CRC32, but with a "polynomial" that differs
from the one in zip (CRC32 is a family of cyclic redundancy checks, from
which I think the authors of the zip specification picked one
arbitrarily). Practical implementations of CRC32 often use a precomputed
table to represent the chosen CRC polynomial, instead of starting from
the mathematical principles, which is what is going on in the code you
quoted. Rainbow tables are something different.

> 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.

That seems entirely reasonable. We can add more as we discover that we
need it, the same way we've incrementally added support for increasingly
horrible container formats.

    S