Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=836840 --- Comment #15 from Hans de Goede <hdegoede@xxxxxxxxxx> --- Hi Alberto, (In reply to comment #14) > Hi Hans, thanks anyway for your answer. Cool to see that you're pursuing getting gtkradiant into Fedora! > I revised my spec and now I think is better than before. Yes much better, but still a lot of work todo. > The build is made through scons, but, and this is the first doubt, every > time I start the rpmbuild process, scons seek and download the whole games > archive from the svn server of the project: > svn.icculus.org/gtkradiant-gamepacks/ > I think isn't normal during the creation of an rpm leave download data from > the internet. I think I should make an archive of files and patch the > sources to avoid download things from the net, shouldn't I? There are a number of problems here: 1) It should not download those gamepacks during the build 2) I wonder what the license on these gamepacks are, chances are that these packs are not licensed under a FOSS license, in which case they should not be packaged at all. Instead you can provide the user with a download script to download them for the user + a README.fedora explaning this. Or you could do a wrapper script around the gtkradiant binary which will ask the user if it is ok to do the download automatically when the user starts gtkradiant for the first time. Try "yum install vavoom" and then run doom-shareware as an example of this. 3) If I'm wrong and these gamepacks are under a FOSS license they should really be packaged in a separate gtkradiant-data.src.rpm As for how to stop scons from doing the download, have you tried removing the setup target from the scons invocation ? > Another problem.. I discovered that the scons process builds, besides > gtkradiant itself, two libraries, libpng and libjpeg. As described in the fp > wiki, I shouldn't include bundled libraries in my rpm, so in my spec I > removed them in the %install section, but I think I also should remove their > creation, to speed up the build. Yes this is the 2nd big problem you will need to solve, you should remove these libraries from the extracted source tree in %prep to make sure that the system version of the libraries and their headers is used during the build. You will then of course also need to fix any scons errors from when it tries to build / install them anyways. > Here is what the upstream said about the embedded libraries: > http://icculus.org/pipermail/gtkradiant/2012-September/011823.html --> > ".. The slightly less common deps (png and jpeg libraries, some old version) > are bundled in to make it simple." > > How can I avoid the build of unneeded libraries? I think I should edit > config.py, around this point > (https://github.com/TTimo/GtkRadiant/blob/master/config.py#L251), Yes you will probably need to do something like that. > think should be made a deep work on it, which I am not able to do. > I've also added the two libraries needed in the Requires tags (libpng12 and > libjpeg-turbo), obtained with 'yum provides libpng.so.? libjpeg.so.62', and > rpmlint complains these are explicit-lib-dependencies. Is this an issue or > should I simply leave > Requires: libpng.so.3 > Requires: libjpeg.so.62 There is no need to add these Requires when you've build the binary against the system copies of the libraries by removing the included copies in %prep then rpm will pick up the Requires automatically. > During the build I've noticed rpmbuild would create strange folders in > /usr/lib/debug/blabla.. and so I've added > %global debug_package %{nil} > at the top of my spec. Is this ok? No, rpm will automatically create a gtkradiant-debuginfo sub-package where these files will get added too, this can then later be used to debug problems with gtkradiant. So you should NOT have a "%global debug_package %{nil}" in your specfile. One last small thing I noticed, currently you have: %global releaseno 6 And: Release: %{version2}.%{releaseno}%{?dist} You've the releaseno and version2 the wrong way around, see: http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Snapshot_packages Also I would not use a global for releaseno, people expect to find (and modify if they change your package) the releaseno in the Release field, So I would just use: Release: 6.%{version2}%{?dist} Regards, Hans -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=czZUxOwkVf&a=cc_unsubscribe _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review