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:
```
++ /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.
Vít
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
