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


 + /usr/bin/gem specification -l --ruby 

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.


Rpm-maint mailing list

Reply via email to