Dne 28.11.2016 v 12:39 Mamoru TASAKA napsal(a): > Vít Ondruch wrote on 11/28/2016 07:41 PM: >> 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 ... > > Honestly speaking, although ruby upstream say that "gem specification" > output > is ruby internal, I don't think such "memory optimization" which may > break things like this should be brought into _PATCH_ release change, > such change should be introduced into at least minor release change, > the best is major release change. > > +1 for reverting this change on stable Fedora.
I reverted this feature for stable Fedoras. Please test the updates: F25: https://bodhi.fedoraproject.org/updates/FEDORA-2016-1270a9a624 F24: https://bodhi.fedoraproject.org/updates/FEDORA-2016-1ce385e9d8 F23 should not suffer this issue. And please don't forget to adjust your packages in Rawhide. Thx Vít > > Mamoru > >> >> >> 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 -- [email protected] >>> To unsubscribe send an email to [email protected] >> >> _______________________________________________ >> ruby-sig mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> > > _______________________________________________ > ruby-sig mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ ruby-sig mailing list -- [email protected] To unsubscribe send an email to [email protected]
