On Tue, Jan 6, 2015 at 7:03 AM, Dominic Cleal <dcleal(a)redhat.com&gt; wrote: Here's the changes I've been making to my gems as I have time: Change Provides: rubygem(%{gem_name}) = %{version} to %if 0%{?fc19} || 0%{?fc20} || 0%{?el7} Provides: rubygem(%{gem_name}) = %{version} %endif And then as each Fedora release goes EOL (F19 is coming up soon), I remove the individual dist tags. I've been wrapping the explicit Requires (such as Requires: ruby(release), Requires: ruby(rubygems), etc) with a similar dist tag conditional, since these should no longer be explicitly listed in the gem .spec file either. - Ken

On Tue, Jan 6, 2015 at 3:11 PM, Allen Hewes <allen(a)decisiv.net&gt; wrote: Sure thing. Here's a patch where I only modified the package for Ruby 2.1 and Minitest 5: http://pkgs.fedoraproject.org/cgit/rubygem-capillary.git/commit/?id=2bba5... The "Ruby 2.1" part of that change was when I added the "%if 0%{?fc19} || 0%{?fc20} || 0%{?el7}" conditionals. The "Minitest 5" part of that change was when I changed the code in %check to run "ruby -Ilib:test -e 'Dir.glob "./test/**/*_test.rb", &method(:require)'" instead of using testrb. I was already touching this rubygem-capillary package in order to fix the Minitest 5 issue (the FTBFS bug, https://bugzilla.redhat.com/1107075), so I decided to implement the Ruby 2.1 changes as well. That's generally how it goes - I will adjust the package to deprecate the explicit Requires/Provides when I get around to it due to other bugs cropping up :) Now that Fedora 19 is EOL, I can go through my gem packages and remove the "0%{?fc19}" dist tag, leaving only the fc20 and el7 ones, so it's a bit less crufty. - Ken

On Tue, Jan 6, 2015 at 9:06 PM, Allen Hewes <allen(a)decisiv.net&gt; wrote: Yeah, that's one of the bigger head-scratchers about gem packaging. When I initially started into Ruby and gems packaging, I was under the impression that Rakefiles were like Makefiles. GNU Make is a small, simple program with well-understood features, and I figured Rakefiles would sort of be like Perl's Makefile.PL - extremely standardized files that pretty much did exactly the same thing from project to project. If each gem just implemented a bare-bones Rakefile that only did "require 'rake/testtask'" or something, that would be the case. However, most Rakefiles end up being a lot more complicated. - If a gem author uses Jeweler for packaging, then the Rakefile tries to load Jeweler, which implies rubygem-jeweler and its depchain have to be present in the buildroot - If a gem uses Hoe for packaging, same deal - we have to BuildRequire: rubygem-hoe - If a gem has a "rake yard" task, we won't use that in Fedora's build, but we'd still need to ensure that yard is available in the buildroot with BuildRequire: rubygem-yard - If a gem uses Bundler, it's quite likely that the Rakefile will require "bundler/setup", or "bundler/gem_tasks", etc. and we try very hard to avoid invoking bundler in Fedora at all. - Some Rakefiles include other clever things to make the upstream authors' lives easier, which also happens to pull in other dependencies, etc. So the problem is that Fedora is only interested in the "rake test" task, but in order to even load the Rakefile with the "rake" command, we have to unconditionally BuildRequire all of that extra stuff. If a GNU Makefile has a command "make this-large-thing-with-lots-of-dependencies", but you only want to run "make test", it's ok if you don't have all the dependencies available on your system. Make will still let you run the command you want to run ("make test") without bothering to check whether you've satisfied every dependency for every possible task it knows about. Sadly Rakefiles don't work that way. I think that's why Rakefiles have a reputation in Fedora for being bloated, and it's why the guidelines recommend against running rake during the build. Maybe if upstreams took greater care to catch LoadErrors for gem dependencies that are truly optional, then this wouldn't be a big deal. I try to submit patches upstream when things are really egregious in spec/spec_helper.rb or test/test_helper.rb. But from upstream's perspective, they often assume the world uses bundler, and all the gems are available for download via rubygems.org anyway, so what's the problem :) We've had to meet in the middle between Fedora's perspective on the world versus the Ruby community's perspective, and sometimes the results aren't as elegant as I would wish. To answer your question about why we just run "ruby -e this-long-and-complicated-copypasta" instead of "testrb", see https://lists.fedoraproject.org/pipermail/ruby-sig/2014-May/001585.html . The gems that use rspec do have a much shorter/saner %check section. - Ken

On Wed, Jan 7, 2015 at 4:13 AM, Vít Ondruch <vondruch(a)redhat.com&gt; wrote: I didn't realize we hadn't updated the guidelines yet! :) Here you go: https://fedorahosted.org/fpc/ticket/489 - Ken

Ken, What's the difference between tickets in fedorahosted.org and bugzilla.redhat.com? The Ruby documentation isn't maintained by folks on ruby-sig@? You have to create a ticket for someone else to update it? /allen ________________________________ Disclaimer Confidentiality Notice: This e-mail, and any attachments and/or documents linked to this email, are intended for the addressee and may contain information that is privileged, confidential, proprietary, or otherwise protected by law. Any dissemination, distribution, or copying is prohibited. This notice serves as a confidentiality marking for the purpose of any confidentiality or nondisclosure agreement. If you have received this communication in error, please contact the original sender.

Vít Ondruch wrote on 01/08/2015 12:30 AM: Well, this was very old craft, added 2 years ago (and the upstream rubygem-test-unit removed testrb 35 months ago). Now I removed this on F-22: http://pkgs.fedoraproject.org/cgit/rubygem-test-unit.git/commit/?id=1187f... Regards, Mamoru