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 -- 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
>>
>
> _______________________________________________
> 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

Reply via email to