Description of problem: ruby -rrbconfig -e 'puts RbConfig::CONFIG["ruby_version"]' returns an empty string using ruby on Rawhide. on F18 the proper version is returned: $ ruby -rrbconfig -e 'puts RbConfig::CONFIG["ruby_version"]' 1.9.1 Version-Release number of selected component (if applicable): ruby-2.0.0.0-4.fc19 How reproducible: Always
You are right. That is coming into that place due to "--with-ruby-version=''" configuration option. Since you can specify there any arbitrary string (if I am not mistaken) using that option, I don't think you get what you want. I am going to reject this issue. If you disagree then we can consider upstream report. Also, if you provide me with your use case, we might find some better option.
This is the reason for the failure of the build of root on Fedora 19 and 20. The root configure script uses this to establish which version of ruby it should be compiled for. Since the returned string is empty the compilation ends up trying to build for 1.8 and earlier which fails since the version in 2.0. Failed scratch build: https://koji.fedoraproject.org/koji/taskinfo?taskID=5146175
The configure script has done it this way since at least 2006.
Created attachment 713677 [details] Do not use ruby_version Well, the "--with-ruby-version=" exists 5 years [1], so in that period, it could happen any time. But if you want something even older, I would suggest using 'MAJOR' and 'MINOR', which exists at least since 1999 [2] and does not changed. I attached patch which does it. Nonetheless, if I apply the patch or not, if I hardcode the #define R__RUBY_MAJOR 1 #define R__RUBY_MINOR 9 into RConfigOptions.h or not, the compilation still fails. It seems to fix the "error: 'rb_frame_last_func' was not declared in this scope" error indeed, there remains other bugs which should be addressed. [1] https://github.com/ruby/ruby/commit/6bc480e059b0b9a6a24dceaa96e2d0717cceca51 [2] https://github.com/ruby/ruby/commit/65a5162550f58047974793cdc8067a970b2435c0
Thank you for your feedback. Root is now buildable again.
*** Bug 953948 has been marked as a duplicate of this bug. ***
*** Bug 1170282 has been marked as a duplicate of this bug. ***
Why does the specfile not just pass "%{ruby_version}.{%teeny_version}" in as the value passed to --with-ruby-version? It's a standard expectation from the Ruby development community, and a reasonable one, that RbConfig::CONFIG['ruby_version'] return the 3-part version of the Ruby VM. All releases of Ruby on all platforms that I've checked (MacOS, Windows, Debian, Ubuntu, older Fedora and RHEL) return the appropriate value from this check. I don't see a technical or useful reason for Fedora to break this expectation. WRT comment #4, yes, we could piece the version information together. But Ruby already sets an expectation for getting this data all together via the ruby_version value in the RbConfig::CONFIG hash.
(In reply to Darryl L. Pierce from comment #8) > Why does the specfile not just pass "%{ruby_version}.{%teeny_version}" in as > the value passed to --with-ruby-version? The parameter is used mainly to setup directory structures, e.g. when you run $ configure --with-ruby-version=foo the resulting structure will look something like this: /usr/lib64/ruby /usr/lib64/ruby/site_ruby /usr/lib64/ruby/site_ruby/foo /usr/lib64/ruby/site_ruby/foo/x86_64-linux /usr/lib64/ruby/foo/ /usr/lib64/ruby/vendor_ruby /usr/lib64/ruby/vendor_ruby/foo /usr/lib64/ruby/vendor_ruby/foo/x86_64-linux /usr/lib64/ruby/gems /usr/lib64/ruby/gems/foo /usr/lib64/ruby/gems/foo/cache /usr/lib64/ruby/gems/foo/doc /usr/lib64/ruby/gems/foo/build_info /usr/lib64/ruby/gems/foo/extensions /usr/lib64/ruby/gems/foo/gems That is what the parameter does. And it is called by coincidence and not very smart ruby_version. Your other claims about "standard expectation" are exaggerated. Everybody who uses this parameter is using it just on his/her wrong assumption, which does not meet reality. Unless you are willing to ignore the minority of Ruby developers who are using Ruby's configuration options, please use the snippet suggested to you by Mamoru [1]. [1] https://lists.fedoraproject.org/pipermail/ruby-sig/2014-December/001705.html
(In reply to Darryl L. Pierce from comment #8) > Why does the specfile not just pass "%{ruby_version}.{%teeny_version}" in as > the value passed to --with-ruby-version? And to answer this question, we removed the version from the paths using --with-ruby-version parameter, because it is useless in Fedora, since we support only single version of Ruby on system. Moreover in times of Ruby 1.9.{2,3}, it was even confusing.
(In reply to Vít Ondruch from comment #10) > (In reply to Darryl L. Pierce from comment #8) > > Why does the specfile not just pass "%{ruby_version}.{%teeny_version}" in as > > the value passed to --with-ruby-version? > > And to answer this question, we removed the version from the paths using > --with-ruby-version parameter, because it is useless in Fedora, since we > support only single version of Ruby on system. Moreover in times of Ruby > 1.9.{2,3}, it was even confusing. Perhaps I'm not being clear? I'm saying that it _is_ useful and is _of use_ to tools, such as gems, that are installed and which need to query the Ruby version at install-time. That it was confusingly used in past, or doesn't fit into someone else's use case, doesn't mean it's "useless". I wish you would reconsider that perhaps others have a need for a standard feature in Ruby rather than just setting it incorrectly and ignoring requests to let the Fedora package behave like _all_ other installations of Ruby.
(In reply to Vít Ondruch from comment #9) > (In reply to Darryl L. Pierce from comment #8) > > Why does the specfile not just pass "%{ruby_version}.{%teeny_version}" in as > > the value passed to --with-ruby-version? > > The parameter is used mainly to setup directory structures, e.g. when you run > > $ configure --with-ruby-version=foo > > the resulting structure will look something like this: > > /usr/lib64/ruby > /usr/lib64/ruby/site_ruby > /usr/lib64/ruby/site_ruby/foo > /usr/lib64/ruby/site_ruby/foo/x86_64-linux > /usr/lib64/ruby/foo/ > /usr/lib64/ruby/vendor_ruby > /usr/lib64/ruby/vendor_ruby/foo > /usr/lib64/ruby/vendor_ruby/foo/x86_64-linux > /usr/lib64/ruby/gems > /usr/lib64/ruby/gems/foo > /usr/lib64/ruby/gems/foo/cache > /usr/lib64/ruby/gems/foo/doc > /usr/lib64/ruby/gems/foo/build_info > /usr/lib64/ruby/gems/foo/extensions > /usr/lib64/ruby/gems/foo/gems > > That is what the parameter does. And it is called by coincidence and not > very smart ruby_version. This last part is your opinion, not a demonstrable fact. > Your other claims about "standard expectation" are exaggerated. Everybody > who uses this parameter is using it just on his/her wrong assumption, which > does not meet reality. Unless you are willing to ignore the minority of Ruby > developers who are using Ruby's configuration options, please use the > snippet suggested to you by Mamoru [1]. Can you please cite where this is a "wrong assumption"? A member of the Ruby team itself in past pointed this out to you and you ignored his statement as well. I think this isn't a case of others being wrong but of you not wanting to listen to a different opinion. > [1] > https://lists.fedoraproject.org/pipermail/ruby-sig/2014-December/001705.html
This is what "./configure --help" says about that parameter: --with-ruby-version=STR ruby version string for version specific directories [[full]] (full|minor|STR) It means that ruby_version may become 1) full => MAJOR.MINOR.TEENY 2) minor => MAJOR.MINOR 3) STR => Any string with empty string exception (and empty string does not apply to fedora). Also you should note that by using ruby_version, you cannot distinguish between Ruby 1.9.{1,2,3}, which is probably not an issue for your use case, but might be issue for others. You can read the rest in the configure.in. And yes, empty string had been disabled without any justification way later [1], after it was already in use in Fedora [2] for more then a year. BTW I obtained the directory structure by setting the "--with-ruby-version=foo" flag. If you'd like to try it yourself, please note that there seems to be bug in Ruby 2.2-preview2 [3]. It used to work for older versions, probably Ruby 2.0.0, without issues. [1] https://github.com/ruby/ruby/commit/c4544321cbab43afe53fb65c1f7e41f02309e64a [2] http://pkgs.fedoraproject.org/cgit/ruby.git/commit/?id=117278abd02a5bf1a482753a93fbe47c52752f6f [3] https://bugs.ruby-lang.org/issues/10572
BTW this [1] is the commit which allowed the above mentioned functionality. [1] https://github.com/ruby/ruby/commit/6bc480e059b0b9a6a24dceaa96e2d0717cceca51
And since the beginning, the only reason for existence of the variable appears to be the configuration of directories, nothing else: https://github.com/ruby/ruby/commit/13cbec33c1335c5e582360797dfce7601bf60206 more intuitive name could be rubylibdir_version or something like this. Unfortunately that did not happened.
(In reply to Vít Ondruch from comment #14) > BTW this [1] is the commit which allowed the above mentioned functionality. > > [1] > https://github.com/ruby/ruby/commit/6bc480e059b0b9a6a24dceaa96e2d0717cceca51 Note that this --with-ruby-version intention is to make 1.8.6 and 1.8.7 parallel installable, not to be set empty: http://permalink.gmane.org/gmane.comp.lang.ruby.devel/9518 (all in Japanese). Note that Kosaki-san says he even wants to compulsorily change ruby source (bug 975660 comment 10) and current Fedora packaging way is clearly against ruby developer intention. I would vote that setting ruby-version as empty is cleary wrong decision.
Vit, you must understand that it is not that Fedora maintainer can do anything what you want , and you must think about upstream point of view, user point view and what other distro do.
(In reply to Vít Ondruch from comment #15) > And since the beginning, the only reason for existence of the variable > appears to be the configuration of directories, nothing else: > > https://github.com/ruby/ruby/commit/13cbec33c1335c5e582360797dfce7601bf60206 > > more intuitive name could be rubylibdir_version or something like this. > Unfortunately that did not happened. Then why not provide a patch upstream with Ruby to do that? But, in the mean time, please configure the Fedora package to return the expected value. Whether you agree with how it's used or not, it causes you no problems to set the value to what's expected by others, and it avoids having Fedora's Ruby deviate from how every other instance of Ruby works in the world.
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle. Changing version to '22'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.