https://bugzilla.redhat.com/show_bug.cgi?id=850469 --- Comment #2 from Vít Ondruch <vondruch@xxxxxxxxxx> --- * Man pages - Wouldn't be better to keep the .pod file in original form, i.e. no tarball? It is so small that the benefits (you can read it in your editor, it could be kept in git and you could diff it easily) would outweigh the negatives (yes, the tarball is few bytes smaller probably, but git compresses its repository anyway). Moreover, you could reference the %{SOURCE1} directly in pod2man command, instead of unpacking and then referring to it. * Do not delete %{gem_instdir}/bin - This is definitely bad idea: $ ascii85 /usr/bin/ascii85:23:in `load': cannot load such file -- /usr/share/gems/gems /Ascii85-1.0.1/bin/ascii85 (LoadError) from /usr/bin/ascii85:23:in `<main>' - The %{_bindir} executable is just stub generated by rubygems and the %{gem_instdir}/bin is the real executable. * BuildRequires: perl - Really? What is it good for? * Test suite - Cannot be executed - See your Koji link referenced above ;) - Adding "BuildRequires: %{_bindir}/rspec" could solve the issue - Not sure why are you using the -P option. Can't see any difference running the test suite with or without it. - I prefer to run the test suite in .%{gem_instdir} instead of %{buildroot}%{gem_instdir}. While not exclusively better, if there is some test suite debris, it will not get into the RPM at least. * Keep the documentation in its original location - I know [1], but unless standardized differently, I'd like to point it out. However not a blocker. * ruby -KU - There are two alternatives which might be better: RUBYOPT="-KU" gem build %{gem_name}.gemspec or LANG=en_US.utf8 gem build %{gem_name}.gemspec [1] http://lists.fedoraproject.org/pipermail/packaging/2012-August/008598.html -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review