https://bugzilla.redhat.com/show_bug.cgi?id=839395

--- Comment #20 from Vít Ondruch <[email protected]> ---
(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
[email protected]
https://admin.fedoraproject.org/mailman/listinfo/package-review

Reply via email to