Re: port of game-data-packager to Fedora

Le mercredi 4 novembre 2015, 13:01:51 Hans de Goede a écrit : >> 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. Ok I'll start with this one, because: - it's the most usefull utility of the two - the most stable too - I can just re-use existing specfile (I have already pinged upstream about this) https://github.com/arx/ArxPackages/blob/master/innoextract/rpm/innoextrac...

> 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: Huh ? The one in Debian uses autoconf https://sources.debian.net/src/htmlcxx/0.85-3.4/configure.ac https://sources.debian.net/src/htmlcxx/0.85-3.4/debian/rules So that's just a 2-lines build there; the remainder is for the manpage. %: dh $@ --with autoreconf > https://github.com/dhoerl/htmlcxx That one seems to be something totally unrelated.

> 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 this point doesn't apply. > So you can simply put a snapshot of this in the > same src.rpm as innoextract / lgogdownloader, > and use that directly. lgogdownloader is the current _single_ reverse dependency for this in Debian, still I'd prefer to do it properly. There, this one is not maitained by the Games team for example; it was packaged by someone else years before lgogdownloader even existed. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=504222 So I'd prefer to keep it separate; this part will likely require less uploads; only when GCC decide to break all C++ packages.

>> 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: Extra hint: InnoSetup (the packager) is free software, albeit windows-only. https://github.com/jrsoftware/issrc/blob/master/license.txt I'll do that; I'll send the mail to fedora-devel > 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). I'm already at the "koji build --scratch f23 rpmbuild/SRPM/innoextract-1.5-1.fc23.src.rpm" step ;-)