[Rpm-maint] %setup for RubyGems

Thierry Vignaud thierry.vignaud at gmail.com
Wed Oct 19 13:30:33 UTC 2016


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


More information about the Rpm-maint mailing list