Bug#884354: game-data-packager: [doom] default behaviour of downloading and packaging e1m{4, 8}b is wrong

[Jonathan Dowland]

On Thu, Dec 14, 2017 at 06:19:21PM +0000, Simon McVittie wrote:
> Now that I've added the activated_by field
>for #775080, they could be marked as activated_by the relevant PWAD,
>meaning they're only packaged if the relevant PWAD is provided on the
>command-line or found to be installed already, or if g-d-p is given the
>new --everything command-line option.

That's great. (In case you haven't guessed, this is me trying to return
to g-d-p).

>The semi-official Quake Episode 5: Dimensions of the Past (by id Software
>licensee MachineGames) should perhaps get activated_by as well.

Noted. Interestingly I didn't hit this problem when packaging up my
quake1 data. I did get the pleasant surprise of having it patched up
from 1.01 to 1.06 and that process "just work"ing, which was lovely.

>You can also use --no-download if that's the behaviour you want.

I am aware of --no-download but my specific issue is with the default
behaviour here (I should have been clearer in my bug. Perhaps grumbling
about the packaging of the PWADs at all served only as a distraction,
since I'm not challenging that.)

>> [ for downloading and playing the thousands of PWADs available for Doom
>>    and Doom engine games, what we need is a F/OSS Linux-supporting Doom
>>    launcher, something quite different to game-data-packager. Possibly
>>    something like "Quake Injector":
>>    https://github.com/hrehfeld/QuakeInjector ]
>
>You're more than welcome to find or write one (and indeed Alexandre
>wrote a launcher for the Doom II Master Levels which might be a
>reasonable basis),

Of course. (I did look briefly at Alexandre's launcher, he posted it to
the Chocolate Doom github, but I need to return to it).

>One thing I've considered doing for g-d-p in future is having "install
>for only me" support, which harvests the right files (that's 90% of g-d-p
>these days), but drops them into ~/.q3a or equivalent instead of actually
>packaging them (the remaining 10%); or using Flatpak, which can install
>either system-wide or locally.

Yes those are both good ideas. Do we no longer have any
hard-dependencies on data packages from game engine packages? I recall
at some point in the past the Fedora Games people looking at g-d-p and
an RPM back end.

>When you wrote the original g-d-p for Doom,
>gathering up the right files was easy because there's only one per Doom,
>and packaging was where all the work went. With many of the games that
>are now supported, the relative difficulty is the other way round:
>knowing what needs to be collected is the hard part, and building a .deb
>(or RPM or whatever Arch uses) is easy because we basically only have to
>implement it once.

That's an interesting perspective, yes. Doom was a simple case and a
good one to start with. We still managed to screw that up (I discovered
that doom-wad-shareware in non-free was not the correct version). The
various patching and chopping up that needs to take place for other
games is where this tool shines.

-- 

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄⠀⠀⠀⠀