Bug 923703 - ruby_version is empty
ruby_version is empty
Status: NEW
Product: Fedora
Classification: Fedora
Component: ruby (Show other bugs)
22
All Linux
unspecified Severity high
: ---
: ---
Assigned To: Vít Ondruch
Fedora Extras Quality Assurance
: Reopened
: 953948 1170282 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-03-20 06:53 EDT by Mattias Ellert
Modified: 2015-06-21 20:08 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-12-05 07:21:33 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Do not use ruby_version (604 bytes, patch)
2013-03-21 05:28 EDT, Vít Ondruch
no flags Details | Diff

  None (edit)
Description Mattias Ellert 2013-03-20 06:53:02 EDT
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
Comment 1 Vít Ondruch 2013-03-20 07:10:25 EDT
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.
Comment 2 Mattias Ellert 2013-03-20 07:24:10 EDT
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
Comment 3 Mattias Ellert 2013-03-20 08:58:20 EDT
The configure script has done it this way since at least 2006.
Comment 4 Vít Ondruch 2013-03-21 05:28:51 EDT
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
Comment 5 Mattias Ellert 2013-03-23 05:34:46 EDT
Thank you for your feedback. Root is now buildable again.
Comment 6 Vít Ondruch 2013-04-22 03:15:41 EDT
*** Bug 953948 has been marked as a duplicate of this bug. ***
Comment 7 Mamoru TASAKA 2014-12-03 19:04:40 EST
*** Bug 1170282 has been marked as a duplicate of this bug. ***
Comment 8 Darryl L. Pierce 2014-12-04 09:22:25 EST
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.
Comment 9 Vít Ondruch 2014-12-05 07:21:33 EST
(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
Comment 10 Vít Ondruch 2014-12-05 07:27:53 EST
(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.
Comment 11 Darryl L. Pierce 2014-12-05 08:10:26 EST
(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.
Comment 12 Darryl L. Pierce 2014-12-05 08:13:15 EST
(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
Comment 13 Vít Ondruch 2014-12-05 08:44:57 EST
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
Comment 14 Vít Ondruch 2014-12-05 08:59:46 EST
BTW this [1] is the commit which allowed the above mentioned functionality.

[1] https://github.com/ruby/ruby/commit/6bc480e059b0b9a6a24dceaa96e2d0717cceca51
Comment 15 Vít Ondruch 2014-12-05 09:11:53 EST
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.
Comment 16 Mamoru TASAKA 2014-12-05 09:13:05 EST
(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.
Comment 17 Mamoru TASAKA 2014-12-05 09:15:11 EST
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.
Comment 18 Darryl L. Pierce 2014-12-05 09:31:41 EST
(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.
Comment 19 Jaroslav Reznik 2015-03-03 09:54:02 EST
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

Note You need to log in before you can comment on or make changes to this bug.