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 to
>>> 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 -- firstname.lastname@example.org
>>> To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
>> ruby-sig mailing list -- email@example.com
>> To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
> ruby-sig mailing list -- firstname.lastname@example.org
> To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
ruby-sig mailing list -- email@example.com
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org