[Rpm-maint] %setup for RubyGems

Vít Ondruch vondruch at redhat.com
Wed Oct 19 10:26:43 UTC 2016



Dne 17.10.2016 v 16:34 Pascal Terjan napsal(a):
> On 17 October 2016 at 15:12, Vít Ondruch <vondruch at redhat.com> wrote:
>>
>> Dne 17.10.2016 v 15:37 Pascal Terjan napsal(a):
>>> On 17 October 2016 at 14:31, Vít Ondruch <vondruch at redhat.com> wrote:
>>>> Dne 17.10.2016 v 15:07 Thierry Vignaud napsal(a):
>>>>> On 17 October 2016 at 12:06, Vít Ondruch <vondruch at redhat.com> wrote:
>>>>>> Dne 17.10.2016 v 11:30 Thierry Vignaud napsal(a):
>>>>>>> On 17 October 2016 at 10:10, Panu Matilainen <pmatilai at laiskiainen.org> wrote:
>>>>>>>>> What is the chance to get [1, 2] into the release? I mildly remember,
>>>>>>>>> that once I was offered to get this patch into Fedora, but that never
>>>>>>>>> materialized and now it is almost a year. I don't think this is
>>>>>>>>> controversial change which should make anything break.
>>>>>>>>>
>>>>>>>>> Thx for considering.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Vít
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> [1] https://github.com/rpm-software-management/rpm/pull/27
>>>>>>>>> [2]
>>>>>>>>>
>>>>>>>>> https://github.com/rpm-software-management/rpm/commit/89d1dd0a7c63c7497d334e9f240ce7e36ca89434
>>>>>>>> Hmm, that has actually been in Mageia for over a year so it's certainly
>>>>>>>> gotten its share of soak-time (so at least it's not breaking anything else)
>>>>>>>> and people are probably depending on it in Mageia so it'd be a reasonable
>>>>>>>> candidate.
>>>>>>> Actually, it's been here at least in Mageia from much more earlier:
>>>>>>> http://svnweb.mageia.org/packages/cauldron/rpm/current/SOURCES/rpm-4.6.1-setup-rubygems.patch?view=markup&pathrev=343
>>>>>>>
>>>>>>> I think the original patch went in in October 2010, previously we were
>>>>>>> using a separate %gem_unpack macro
>>>>>>>
>>>>>>> But it's not the same implementation as the one that has been merged
>>>>>>> in master. Mageia one is:
>>>>>>> http://svnweb.mageia.org/packages/cauldron/rpm/current/SOURCES/rpm-4.12.90-setup-rubygems.patch?revision=860276&view=markup
>>>>>>>
>>>>>>> But if it works the same, Mageia will be happy to drop one more patch :-)
>>>>>> They are a bit different indeed. These are two main differences I can see:
>>>>>>
>>>>>> 1) The upstream patch is using 'gem' command to unpack the sources
>>>>>> instead of using 'tar'. The advantage of this approach is that it should
>>>>>> be always able to unpack every gem. Please note that historically, the
>>>>>> .gem format was internally different and the format might change again
>>>>>> in the future. The disadvantage is the dependency on external tool, but
>>>>>> this is just soft dependency, since RPM can handle the missing 'gem'
>>>>>> command gracefully.
>>>>>>
>>>>>> 2) There is provided the %{gem_name}.gemspec file alongside the unpacked
>>>>>> code, which is in Fedora used to repackage patched gem, prior installation.
>>>>> 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.

So how is your testing going? ;)


Vít


More information about the Rpm-maint mailing list