port of game-data-packager to Fedora

[Hans de Goede]

Hi,

On 11/03/2015 11:57 AM, Alexandre Detiste wrote:
> The fedora support branch has now been completely merged in master :-)
>
> Running it from the git tree is explained here:
>
> http://anonscm.debian.org/cgit/pkg-games/game-data-packager.git/tree/doc/adding_a_game.mdwn
>
> $ git clone https://anonscm.debian.org/git/pkg-games/game-data-packager.git
> $ make
>
> "Then the `./run` command can be used instead of the
> system-installed `game-data-packager` command."
>
>
> Le mardi 3 novembre 2015, 09:54:35 Hans de Goede a écrit :
>>
>> Cool! Do you plan to maintain this for Fedora/rpmfusion in the long
>> run or is this just a way to exercise your Fedora skills and if we want
>> to make use of this do we need to find someone to step up from the
>> rpmfusion community to maintain this ?
>
> I'm now running it thourgh virtualbox, maintenance will be more bearable
> when I manage to run it in a thin container with full X/OpenGl support.
> (systemd-nspawn ?)

Ok, so you do plan to maintain it, that would be great as we
are currently having a shortage of active packagers for rpmfusion.

> The LXC recipe I have at hand doesn't work anymore:
> https://github.com/lxc/lxc/issues/626

I'm afraid I cannot help there.

> ---
>
> I managed to build the "dumb" noarch rpm's produced by G-D-P by using
> a simple "%files" stanza and shoving the generated specfiles to "rpmbuild -bb";
> but I have more difficulties in writing G-D-P's own .spec file,
>
> It should be really easy to package by someone who is used to;
> one just needs to do 'make ; make check'
> and fill version.py with constants:
>
> http://anonscm.debian.org/cgit/pkg-games/game-data-packager.git/tree/debian/rules
>
> ---
>
> The generated .rpm always go to ~/rpmbuild/RPMS/noarch/
> where the default is $(pwd) on Debian; I didn't found a simple
> way to overide this, but maybe that's not desired and
> it's better to remove the "--destination" option.

You can pass:

--define "_rpmdir $(pwd)"

to rpmbuild to use the cwd as output dir, the rpms will then be written
to $(pwd/noarch I do not believe there is a way to get rid of the "noarch"
part of the path.

> Having a option not to compressing 2GB rpm's that'll be used locally
> or rpm's that are zipfile + little else (like Quake .pk? archives) would
> be nice too.

Erm, I'm pretty sure you can do that too, but I do not know how.

> ---
>
> All scummvm & z_code games (Zork, H2G2) should already work as-is.
>
> For the other games, the assets are located where the Debian-packaged
> engines except those, thus mostly in /usr/share/games/<something>
>
> See "grep usr/share/games data/*.yaml".
>
> So each engine needs to be reviewed.

Yeah, we typically put game-data under /usr/share/foo rather then
/usr/share/games/foo. But for things like scummvm you likely also
provide a .desktop for the game, passing in the right options to
start the game ?  Then using /usr/share/games should be fine.

>
> ---
>
> Bonus: the git tree also include a launcher for the
> "Master Levels for Doom II"; you may want to generate
> a seperate .rpm with this:
>
> https://wiki.debian.org/Games/MasterLevelsForDoomII
>
> Thnigs like "['update-alternatives', '--list', 'doom']"
> needs porting; I'll handle that.

<snip>


>>> Two interresting dependencies of G-D-P I didn't found in rpmfusion
>>> are innoextract & lgogdownloader; when installed a setup....exe
>>> sold by GOG.com can be automaticaly downloaded & repacked as a .rpm
>>
>> That is cool, what are the licenses of these 2 utilities ?
>
> Both are in Debian/main,
> - innoextract is MIT licensed & also has it's own rpm repository
> - lgogdowloader is 'What The F**k' licensed (=~MIT)
>
> innoextract is now pretty much done,
> but lgogdownloader can break anyday when GOG.com changes it's API;
> so this needs more frequent updates like youtube-dl .

Ok, so license wise both can go to Fedora proper rather then rpmfusion.

innoextract definitely should go to Fedora proper.

lgogdownloader is more interesting. Which also makes me wonder about
game-data-packager itself. I really do not see any reason for them not to
be in Fedora proper, but I must admit it sort of a gray area.

I think you may want to mail Tom Callaway <tcallawa at redhat.com>
about how acceptable both of them are for Fedora. He is the go to
persons for questions like these, and any answer he gives is the
definitive answer.

Regards,

Hans