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"
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:
F23 should not suffer this issue. And please don't forget to adjust your
packages in Rawhide.
> 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.
>>> 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
>> consequences, it is not acceptable for me. I don't think that the
>> allocation was new issue introduced in rubygems 2.5.x, so it is not
>> regression. But somebody else might have different opinion and of
>> 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
>> expect that with patch version change, the output will be still the
>> 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
>> 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
>> . 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.
>> ruby-sig mailing list -- ruby-sig(a)lists.fedoraproject.org
>> To unsubscribe send an email to ruby-sig-leave(a)lists.fedoraproject.org
> ruby-sig mailing list -- ruby-sig(a)lists.fedoraproject.org
> To unsubscribe send an email to ruby-sig-leave(a)lists.fedoraproject.org
ruby-sig mailing list -- ruby-sig(a)lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-leave(a)lists.fedoraproject.org