[Rpm-maint] %setup for RubyGems

[Thierry Vignaud]

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