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
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 ;-)
But I get a timeout &
https://fedoraproject.org is down too; will continue later.
I'll also provide you my own spec files; not only the one I copied from someone else.
Regards,
Alexandre