Hi,
On 07-11-15 18:23, Alexandre Detiste wrote:
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/innoextract.spec
Ok, for those reading along this one is being reviewed here now:
https://bugzilla.redhat.com/show_bug.cgi?id=1279175
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.
Ok my bad, if it uses autoconf and a straight-forward build, then by
all means do package it for Fedora.
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.
Ack, as said if it is a proper lib with autoconf packaging it separately
makes perfect sense.
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 ;-)
Great :)
Regards,
Hans
