I'm seeing the following message in the build failure in the gem I maintain, asciidoctor:
+ rm Rakefile + sed -i 's|"Rakefile",||g' asciidoctor.gemspec + exit 0 Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.0fctL3 + umask 022 + cd /builddir/build/BUILD + cd asciidoctor-1.5.4 + gem build asciidoctor.gemspec WARNING: See http://guides.rubygems.org/specification-reference/ for help ERROR: While executing gem ... (Gem::InvalidSpecificationException) ["Rakefile"] are not files
That sed expression is highly dependent on how files are specified in a gemspec, and it doesn't match how the asciidoctor gemspec defines files. Can this alteration be updated to be more robust?
One way would be to look for the files assignment and subtract an entry from it. Something like:
sed -i "s|.files *=.*|& - ['Rakefile']|" asciidoctor.gemspec
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
Hi Dan,
This is where it started:
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.o...
Dne 3.3.2017 v 09:36 Dan Allen napsal(a):
I'm seeing the following message in the build failure in the gem I maintain, asciidoctor:
- rm Rakefile
- sed -i 's|"Rakefile",||g' asciidoctor.gemspec
- exit 0
Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.0fctL3
- umask 022
- cd /builddir/build/BUILD
- cd asciidoctor-1.5.4
- gem build asciidoctor.gemspec
WARNING: See http://guides.rubygems.org/specification-reference/ for help ERROR: While executing gem ... (Gem::InvalidSpecificationException) ["Rakefile"] are not files
That sed expression is highly dependent on how files are specified in a gemspec, and it doesn't match how the asciidoctor gemspec defines files. Can this alteration be updated to be more robust?
Yep, there is plan to do this more robust, but somebody needs to execute it :) I hope one day we will have macro similar to %gemspec_{add,remove}_dep, which I introduced in response to these issues. These macros handle the more common case, where we need to modify the gem dependencies.
One way would be to look for the files assignment and subtract an entry from it. Something like:
sed -i "s|.files *=.*|& - ['Rakefile']|" asciidoctor.gemspec
There are several ways how to fix these issues, but unless you use Ruby to modify the .spec file they will break sooner or later. Actually, if you use Ruby, it will break as well, but the chances are that it will break later ;)
And there are several solutions to your issue I can see:
1) Your proposal looks interesting. 2) My first though was:
~~~ @@ -73,7 +73,7 @@ sed -i -e 's|#!/usr/bin/env ruby|#!/usr/bin/ruby|' \
# Clean up development-only file rm Rakefile -sed -i "s|"Rakefile",||g" %{gem_name}.gemspec +sed -i -r "s|"Rakefile"(.freeze)?,||g" %{gem_name}.gemspec
%build gem build %{gem_name}.gemspec ~~~
3) And my second though was: "Why are you removing the file on this place at all?". If you did just this:
~~~ @@ -71,10 +71,6 @@ gem spec %{SOURCE0} -l --ruby > %{gem_name}.gemspec sed -i -e 's|#!/usr/bin/env ruby|#!/usr/bin/ruby|' \ bin/%{gem_name} bin/%{gem_name}-safe
-# Clean up development-only file -rm Rakefile -sed -i "s|"Rakefile",||g" %{gem_name}.gemspec - %build gem build %{gem_name}.gemspec %gem_install -n %{gem_name}-%{version}%{pre}.gem @@ -84,7 +80,7 @@ gem build %{gem_name}.gemspec # Asciidoctor tests require Minitest 5, so we can't run them on EPEL %else # We need many more packages to run the tests. I'll try to work on those deps -# LANG=en_US.utf8 ruby -I"lib:test" test/*_test.rb +LANG=en_US.utf8 ruby -I"lib:test" test/*_test.rb %endif
%install @@ -107,6 +103,7 @@ cp -a .%{gem_instdir}/man/*.1 \ %exclude %{gem_instdir}/man %exclude %{gem_instdir}/test %exclude %{gem_instdir}/features +%exclude %{gem_instdir}/Rakefile %license %{gem_instdir}/LICENSE.adoc %doc %{gem_instdir}/CHANGELOG.adoc %doc %{gem_instdir}/CONTRIBUTING.adoc ~~~
(or you could remove the Rakefile in %install section if you prefer), the result would be the same and it would save you some troubles.
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.
In most cases, it is really easier to exclude the file or rm it in %install section. But there are certainly packages where there is more reasons to remove some files (e.g. there are removed some files by patches applied in %prep section in rubygem-fog, so the .gemspec needs to be adjusted). So long term, I'd really like to see some macro which can cope with this.
Vít
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
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
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/429f883210f8b2b38ea310f7fc6636cd...
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 mailto:ktdreyer@ktdreyer.com> wrote:
On Fri, Mar 3, 2017 at 1:36 AM, Dan Allen <dan.j.allen@gmail.com <mailto: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 <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 <mailto:ruby-sig@lists.fedoraproject.org> To unsubscribe send an email to ruby-sig-leave@lists.fedoraproject.org <mailto: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
ruby-sig@lists.fedoraproject.org
-
Dan Allen -
Ken Dreyer -
Vít Ondruch