Dne 17.10.2016 v 16:34 Pascal Terjan napsal(a): > On 17 October 2016 at 15:12, Vít Ondruch <vondr...@redhat.com> wrote: >> >> 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. > 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 _______________________________________________ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint