On Tue, Jan 6, 2015 at 7:03 AM, Dominic Cleal dcleal@redhat.com wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 06/01/15 13:53, Darryl L. Pierce wrote:

...

Have we decided to eliminate:

Provides: rubygem(%{name}) = %{version}

from the specfiles? I have an update for a gem I maintain and rpmlint is complaining that the line is redundant. Maybe I missed where we announced that such things are no longer needed in Ruby gem packages?

Yes, they're no longer needed from F21 onwards as they're auto-generated at build time. (See contents of rubygems-devel.)

https://fedoraproject.org/wiki/Packaging:Ruby?rd=Packaging/Ruby#RubyGems https://fedorahosted.org/fpc/ticket/409

Remember to keep them for EPEL and pre-F21 releases - I've come across a few instances recently (in and outside of Fedora) where they've been removed on older branches and builds.

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@decisiv.net wrote:

Could you provide a link or sample (like you did above)?. I'm interested... I need to be spoon fed sometimes. ;-)

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=2bba5fe9...

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@decisiv.net wrote:

I have seen something similar (ruby -Ilib:test -e '...') to this in Fedora rubygem- packages. I don't quite understand why this would be done vs testrb or even use the gems' supplied method for running its' test suite (e.g. rake test).

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@redhat.com wrote:

Dne 7.1.2015 v 06:07 Ken Dreyer napsal(a):

...

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.

Ha, this reminds me that the guidelines should be updated finally. Any volunteer? :)

I didn't realize we hadn't updated the guidelines yet! :)

Here you go: https://fedorahosted.org/fpc/ticket/489

- Ken

Vít Ondruch wrote on 01/08/2015 12:30 AM:

Dne 7.1.2015 v 15:59 Ken Dreyer napsal(a):

...

On Wed, Jan 7, 2015 at 4:13 AM, Vít Ondruch vondruch@redhat.com wrote:

...

Dne 7.1.2015 v 06:07 Ken Dreyer napsal(a):

...

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.

Ha, this reminds me that the guidelines should be updated finally. Any volunteer? :)

I didn't realize we hadn't updated the guidelines yet! :)

Here you go: https://fedorahosted.org/fpc/ticket/489

Magnificent! Thank you Ken.

BTW Mamoru, what is your plan with regards to rubygem-test-unit and testrb2? Shouldn't we deprecate it as well? Does it even work currently? There does not look to be %{gem_instdir}/bin in test-unit anymore and with Ruby 2.2, the way how the testrb2 is created [1] will fail.

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=1187f8ae...

Regards, Mamoru

...

Ha, this reminds me that the guidelines should be updated finally.

Any

...

volunteer? :)

I didn't realize we hadn't updated the guidelines yet! :)

Here you go: https://fedorahosted.org/fpc/ticket/489

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.