Actually, since there were some people hitting this issue on devel ML, shouldn't we revert this patch for stable Fedoras? I.e. 23-25 and keep it for Rawhide only? There are two days left until the updates become stable ...
Vít Dne 22.11.2016 v 12:46 Vít Ondruch napsal(a): > > Dne 21.11.2016 v 17:33 Jason Frey napsal(a): >> Here's the Pull Request and commit that introduced the change. >> >> https://github.com/rubygems/rubygems/pull/1371 >> >> The Pull Request shows that the purpose of the change is to fix a memory >> allocation issue. On large projects with a number of Rubygems it can reduce >> String allocations by nearly 50%. I think this is an acceptable bug fix >> with respect to SemVer. > Thx for the pointer. It might or might not be acceptable. Looking at the > consequences, it is not acceptable for me. I don't think that the memory > allocation was new issue introduced in rubygems 2.5.x, so it is not > regression. But somebody else might have different opinion and of course > sometimes it is hard to foresee the consequences. In this case I would > rather hear "sorry and will try to not break things next time for you" ... > >> Additionally, SemVer is around versioning of the public API. As the Gem >> specification source that is generated by Rubygems is not actually part of >> the public API, I don't even think SemVer applies. > So output of "gem spec" is not public API? How comes? Is it too much to > expect that with patch version change, the output will be still the same > unless it explicitly changed to fix some regression? > >> Modifying them (via sed, no less) is akin to monkey-patching private >> methods, which is not covered by SemVer. >> >> May I suggest that instead of using sed against the source > There are cases where sed is used and other cases where the .gemspec > files are patched. I prefer "sed" a bit, because althouhg its a bit more > fragile, it is more flexible on the other hand. > >> , which could potentially corrupt the file into invalid Ruby, that we use >> Ruby to parse Ruby itself? Since the file is valid Ruby, Ripper could be >> use to parse the source, manipulate the S-expressions, and then emit the >> valid, modified Ruby. This feels more forward-compatible in the long run. > This is good tip and just recently, I introduced some macros into > Fedora, which are using similar approach, just using RubyGems constructs > [1]. I find it simpler to understand. > > But the thing is that I know just about breakages in my packages, but I > don't know what else is broken and what different approaches people are > using to modify the .gemspec. Yes, removing some files from .gemspec > file list looks to be something one needs to do from time to time, but > so far it was not that common practice to invest energy to something > more complex then sed/patch. > > > Vít > > > > > [1] > http://pkgs.fedoraproject.org/cgit/rpms/ruby.git/tree/macros.rubygems#n61 > > _______________________________________________ > ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org > To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org _______________________________________________ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
