I'd say that when RubyGems were designed, the idea was to be able to run the test suite of the installed package. But this possibility was remove since RubyGems 1.5 [1], which is quite long time ago. Does anybody remember this? Does anybody missing this? I don't think so ...

From my experience packaging gems for Fedora and always trying to execute the test suite, I can assure you that it is sometimes quite hard to make the test suite running, since it typically requires some preconditions or it tests for several versions of Ruby and Rails and what not. So to be honest, I am not mad about upstreams not shipping their test suites.

Taking Rails as and example, they removed the test suite from the gems quite long time ago. For example they stopped shipping the test suite in ~ ActiveSupport 2.3.8 in 2010.

Don't take me wrong, I am not suggesting to drop all the test suites from all Gems immediately, because honestly, it is more work for me at the end (because I need to include snapshot of the test suite in separate tarball). But on the other hand shipping .gitignore and .travis.yml? These are hardly justifiable. These are typically included, because upstream does something like "spec.files = `git ls-files`" and job done.

Btw usage of Rake in Fedora .spec files is generally discouraged, mainly due to dependency bloat.


Vít


[1] https://github.com/rubygems/rubygems/commit/429f883210f8b2b38ea310f7fc6636cd0e456d5c


Dne 27.3.2017 v 00:38 Dan Allen napsal(a):
Ken,

Great question. I'll admit I'm drifting around without clear direction trying to find the right files to package. My working theory is that it should be possible to run the tests and rebuild the gem file from the files in the gem. In that case, the Rakefile is needed.

Could I propose that if you're going to use a different version of the Rakefile when building the package, that you specify the location of that file using:

rake -f Rakefile.fedora

That seems to tell a more accurate story and does not risk a collision with what the gem provides. It also seems easier to adapt to the external world rather than change it.

I'm happy to rethink how I'm packaging the gem. I'm just explaining my thought process so you understand why I've been doing what I've been doing.

Cheers,

-Dan

On Sun, Mar 26, 2017 at 3:13 PM, Ken Dreyer <ktdreyer@ktdreyer.com> wrote:
On Fri, Mar 3, 2017 at 1:36 AM, Dan Allen <dan.j.allen@gmail.com> wrote:
> Until this is fixed, my gem is going to fail in rawhide because I can't
> change the already released gem. I suspect there are others that are failing
> as well.

Dan, I've been thinking about this issue recently. It looks like
you're purposefully including Rakefile in asciidoctor.gemspec. What is
the purpose of including Rakefile there?

Thinking about the general problem of gemspec surgery in Fedora
packaging, maybe we should take the approach that we should try to
convince upstream developers to stop shipping the files that we
surgically remove in Fedora. For example:
https://github.com/cjheath/geoip/pull/67

I think this would be an easy sell for the things like .travis.yml or
.gitignore. But if if we can't convince the upstream developers to
drop particular extraneous files from their gems, then maybe we should
give up and include those files in Fedora as well.

- Ken
_______________________________________________
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-leave@lists.fedoraproject.org



--
Dan Allen | @mojavelinux | https://twitter.com/mojavelinux


_______________________________________________
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-leave@lists.fedoraproject.org