Dne 17.10.2016 v 15:37 Pascal Terjan napsal(a):
> On 17 October 2016 at 14:31, Vít Ondruch <vondr...@redhat.com> wrote:
>>
>> Dne 17.10.2016 v 15:07 Thierry Vignaud napsal(a):
>>> On 17 October 2016 at 12:06, Vít Ondruch <vondr...@redhat.com> wrote:
>>>> Dne 17.10.2016 v 11:30 Thierry Vignaud napsal(a):
>>>>> On 17 October 2016 at 10:10, Panu Matilainen <pmati...@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.


Vít



[1]
http://svnweb.mageia.org/packages/cauldron/ruby-RubyGems/current/SOURCES/rubygems.macros?revision=910252&view=markup
[2]
https://lists.fedoraproject.org/pipermail/ruby-sig/2015-November/001819.html

_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Reply via email to