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.
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]
