port of game-data-packager to Fedora

[Hans de Goede]

Hi,

On 03-11-15 17:07, Alexandre Detiste wrote:
> Le mardi 3 novembre 2015, 14:49:47 Hans de Goede a écrit :
>>
>>> 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.
>
> Yes I can maintain this one package.
>
> I don't like the "summer of code" mindset of releasing something
> half done & then disapear. I'm also interrested into Fedora
> users contributing details of games(/versions) missing.

That is great!

>>> 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.
>
> It's a bit ugly, but --define "_rpmdir /tmp" might be of use
> if user want to install package right away without keeping the rpm.
>
>>> 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.
>
> I found what I needed : "%define _binary_payload w0.gzdio"
> &  "%define _binary_payload w1.gzdio" .
>
>>> 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.
>
> Yes, indeed when a .desktop file is also generated, the assets can go anywhere;
> residualvm is also already ok.
>
>>>>> 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.
>
> Both of these utilities are just a single C++ binary built with cmake + boost;
> so it should have been easy to build those by hand, but Fedora is lacking
> two dependecies: rhash & htmlcxx .
>
> So this is now 4 packages that are needed :-(
>
> I found a recipe here:
>
> http://webcache.googleusercontent.com/search?q=cache:i-GMQKVEu58J:xmodulo.com/download-gog-games-command-line-linux.html+&cd=3&hl=fr&ct=clnk&gl=us
>
> I think I can handle a noarch python package, but when it comes to C++
> packages that needs extra versioned libraries that gets a bit more difficult to handle.
>
> So for now I'll just use/suggest the innoextract package provided by upstream.

I do not think this is a good idea, we really want to do this properly.

I've taken a quick look, packaging rhash should be easy, it comes
with Makefile-s which properly generate versioned .so libs with a
proper soname at all, and honor DESTDIR, so packaging it really is
not a big deal. And this will actually be a good exercise for showing
that you know the basics of rpm packaging, which is requires to
become a Fedora / rpmfusion packager.

As for htmlcxx it does not come with a buildsys at all, and:

https://github.com/dhoerl/htmlcxx

States:

"The code here is designed to be incorporated directly in your Mac or iOS project and not as a library."

So this is what in Fedora we call a copylib, and bundling those is ok,
esp. when upstream does not provide any sort of (API) versioning
what so ever. So you can simply put a snapshot of this in the
same src.rpm as innoextract / lgogdownloader, and use that
directly.

>> 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.
>
> lgogdownloader can also be used to download pay-per-view indie movies
> about My Little Pony fans and other things...
>
> http://www.gog.com/movie/bronies_the_extremely_unexpected_adult_fans_of_my_little_pony
>
> I wouldn't fight over inclusion of this or G-D-P in Debian main,
> so here also I won't either.
>
> I already got 2 relevant answers here before posting to rpmfusion ML:
>
> https://lists.fedoraproject.org/pipermail/games/2015-November/thread.html

Ok, forget my previous comment asking to put this in Fedora then, lets
just put these 2 in rpmfusion nonfree. I still believe that innoextract belongs
in Fedora proper, so a first step at getting g-d-p in rpmfusion would be
to get innoextract into Fedora, see:

https://fedoraproject.org/wiki/Join_the_package_collection_maintainers

I can act as a sponsor for you in Fedora. I believe this is the best
way to process because of 2 reasons:

1) rpmfusion currently is overhauling its infra, so getting any new
pkgs in atm is kinda hard
2) rpmfusion requires a sponsor process for non Fedora packages just
like the Fedora process, but once you're an official Fedora packager
you get the same rights in rpmfusion automatically

Note the list at:

https://fedoraproject.org/wiki/Join_the_package_collection_maintainers

Looks much longer / more complicated then the process actually is a lot
of steps are very quick. The most work is finding a sponsor (done already :)
and getting a few initial packages reviewed by your sponsor (that would be me).

Regards,

Hans