[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [game-data-packager] Optional licenses

On Wed, 06 Jan 2016 09:30:10 +0100, Alexandre Detiste
<alexandre.detiste@gmail.com> wrote:
> Using alternatives for "The Dig" & a new separate package
> for "Cruise for a Corpse" seems the right things to do.

Credit where credit is due, you suggested the alternatives ;-).

> Scummvm is really resilient to abuse and would continue
> to work if the original XORed digtxt.trs (see hereunder)
> had been replaced by a fan-edited one
> or the fonts bitmaps had been slightly edited;
> so we can safely mix & match assets
> (altough in practice, the looked-up paths
> are scanned in a predictive order, so that wouldn't happen
> unless some files from directory n°1 are missing)

Yes, so for end-users it doesn't really matter. But when preparing updates to
the YAML files, I like to ensure the new description is complete and
self-sufficient, *and* tries to only pick a single set of resources;
otherwise I often end up with a generated .deb which works but picked things
up from a bunch of different places (in this particular instance I was bitten
by old forgotten installations in /usr/local/share/scummvm). The features
which are great for end-users make it harder to be 100% sure a set of asset
descriptions is accurate...

> We're trying to identify the different versions in the most accurate way;
> instead of having "GOG's version", "Simon's version", "Fabian's version".

Indeed. "GOG's version" would make sense in some cases perhaps, but "Simon's
version" or whatever should really end up being "Kixx release" or "LucasArts
Classics Collection French CD" or something like that... Unfortunately this
tends to not be well documented. Should we start systematically adding
provenance to the checksums we add?

One thing I noticed when preparing these updates is that we can't use the
checksums we have in g-d-p to cross-reference releases documented in ScummVM;
they limit their checksums to the first 5000 bytes by default.



Attachment: pgplnXGk7vh7J.pgp
Description: OpenPGP digital signature

Reply to: