[prev in list] [next in list] [prev in thread] [next in thread] 

List:       rpmorg-maint
Subject:    [Rpm-maint] %setup for RubyGems
From:       thierry.vignaud () gmail ! com (Thierry Vignaud)
Date:       2016-10-19 13:32:50
Message-ID: CAONrEtbhwcq3e3FiAKaEyDOCsgqZ+NzsCk3r2BmLF3My0b28hA () mail ! gmail ! com
[Download RAW message or body]

On 19 October 2016 at 15:30, Thierry Vignaud <thierry.vignaud at gmail.com> wrote:
> On 19 October 2016 at 13:24, Pascal Terjan <pterjan at gmail.com> wrote:
> > > > > > > > As it turns out, there's at least one other difference which breaks
> > > > > > > > build for us:
> > > > > > > > eg for ruby-gemcutter
> > > > > > > > (http://svnweb.mageia.org/packages/cauldron/ruby-gemcutter/current/SPECS/ruby-gemcutter.spec?revision=947391&view=markup)
> > > > > > > >  our implementation creates eg:
> > > > > > > > BUILD/ruby-gemcutter-0.7.1
> > > > > > > > whereas the patch merged upstream creates eg:
> > > > > > > > BUILD/gemcutter-0.7.1
> > > > > > > > 
> > > > > > > > This breaks the couple packages I tried.
> > > > > > > > This would need to patch the macros we ships with ruby-RubyGems
> > > > > > > > (see attached rubygems.macros.diff)
> > > > > > > So in reality you did not get the sources calling the %setup macro, you
> > > > > > > actually unpacked just the first level archive and unpacking of the
> > > > > > > second level archive is handled by %gem_setup, right? The 'gem unpack'
> > > > > > > in upstream patch does this in single step.
> > > > > > > 
> > > > > > > And I'd say that you should be able to simplify the %gem_setup macro
> > > > > > > even more, since the lines:
> > > > > > > 
> > > > > > > ```
> > > > > > > if [ ! -f %{gem_name}.gemspec ]; then \
> > > > > > > %{_bindir}/gem specification -l --ruby %{SOURCE0} > %{gem_name}.gemspec \
> > > > > > > \ fi \
> > > > > > > ```
> > > > > > > 
> > > > > > > are covered by RPM now, as can be seen in your log:
> > > > > > Yes that's good
> > > > > > 
> > > > > > > ```
> > > > > > > ++ /usr/bin/gem spec \
> > > > > > > /home/tv/mga/pkgs/N/ruby-gemcutter/SOURCES/gemcutter-0.7.1.gem --ruby \
> > > > > > > ``` 
> > > > > > > vs
> > > > > > > 
> > > > > > > ```
> > > > > > > + /usr/bin/gem specification -l --ruby \
> > > > > > > /home/tv/mga/pkgs/N/ruby-gemcutter/SOURCES/gemcutter-0.7.1.gem ```
> > > > > > > 
> > > > > > > 
> > > > > > > Actually, the log itself would be more useful, since I suspect that in
> > > > > > > the %build section, you rebuild the gem, which is using the .gemspec
> > > > > > > file somewhere, but that was stripped out from the diff.
> > > > > > Yes and actually we have the code twice for the gemspec...
> > > > > > 
> > > > > > -14: gem_build
> > > > > > if [ ! -f %{gem_name}.gemspec ]; then
> > > > > > %{_bindir}/gem specification -l --ruby %{SOURCE0} > %{gem_name}.gemspec
> > > > > > fi
> > > > > > %{_bindir}/gem build %{gem_name}.gemspec
> > > > > Yes, I can see that in [1] now. You should be good to simplify the
> > > > > %gem_build to:
> > > > > 
> > > > > ```
> > > > > %gem_build \
> > > > > %{_bindir}/gem build ../%{gem_name}-%{version}.gemspec
> > > > > ```
> > > > > 
> > > > > These were the changes I proposed for Fedora [2].
> > > > > 
> > > > > Please note that the .gemspec file one directory level above the sources
> > > > > has the advantage, that it does not collide with .gemspec, which might
> > > > > be shipped with the gem itself and it is always completely different
> > > > > from the generated .gemspec.
> > > > Yes that's true, even if I have never noticed a gem containing a
> > > > versioned gemspec name so far
> > > > 
> > > 
> > > I just realized, that with the upstream patch, you can even drop the sed
> > > from %gem_setup, since the .gemspec extracted from .gem file never
> > > contains any "git ls-files" entries. Not sure about the version though.
> > 
> > Yes I realized that too, for some reason I believed we were using a
> > versioned gemspec but we are not and sometimes use the provided one
> > which is the source of all the hacks :)
> > 
> > > So how is your testing going? ;)
> > 
> > I didn't have time to look into it, Thierry would you mind switching
> > to that patch in our package?
> > I can update the rubygems.macros tonight and try to rebuild everything
> > + check the packages tomorrow
> 
> Done in rpm-4.13.0-0.rc1.36.mga6

Argh, it's rpm-4.13.0-0.rc1.37.mga6


[prev in list] [next in list] [prev in thread] [next in thread]