https://bugzilla.redhat.com/show_bug.cgi?id=839395 --- Comment #20 from Vít Ondruch <vondruch@xxxxxxxxxx> --- (In reply to comment #19) > I'm not sure I completely understand your stance on patch1. Are you saying > that no changes to the gemspec are needed? Currently the Gemfile pulls all > gem dependencies from the gemspec. If the gemspec isn't patched to label > the test dependencies as development only I believe the library will fail to > load. Ah, sorry ... I overlooked that. You are right. > I am curious about the dangers of using the upstream gemspec. If there is > any documentation on this I would be happy to read through it! Well, there is no documentation, except my argument with FPC [1, 2]. But gaining more experiences with this approach, I am still firmly convinced (unless [3] unveils something unexpected) that repackaging of gems is wrong. My biggest concern with regards of you package is, that you actually cannot know what files will appear in the resulting .gem. For example, if you do "rpmbuild -bb your.spec" followed by "rpmbuild -bp your.spec", you'll see, that the BUILD directory contains bunch of files comming from the gem and among them, there is "usr" directory for example. But there might be other files as well. If you take the .gempsec produced by the "gem spec" command, there is at least already expanded list of all files which were contained in the original gem, (in contrary to upstream's .gemspc, where is used some globbing) therefore lower chance, that some arbitrary file will endup in the repackaged gem. Somebody, who will take you example my fail, because upstream used "git ls-files" to populate the files list, but the gem does not contain the git metadata. Another problem might be, that the upstream's .gemspec contains some arbitrary code. On the other hand, the .gemspec produced by "gem spec" command was undergone transformation into YAML, so there cannot be everything. So to conclude, it might work in your hands, but it can be "disaster" in others hands. Therefore I discourage this practice. [1] https://fedorahosted.org/fpc/ticket/134 [2] http://lists.fedoraproject.org/pipermail/packaging/2012-February/008192.html [3] http://lists.fedoraproject.org/pipermail/ruby-sig/2012-August/001088.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