Bug 170540 - ancient ruby version is shipped with enterprise (1.6.8 vs 1.8.3)
ancient ruby version is shipped with enterprise (1.6.8 vs 1.8.3)
Status: CLOSED DEFERRED
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: ruby (Show other bugs)
3.0
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Akira TAGOH
Bill Huang
n/a
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-10-12 13:51 EDT by ara howard
Modified: 2007-11-30 17:07 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-10-12 20:30:10 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description ara howard 2005-10-12 13:51:01 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920 Firefox/1.0.7

Description of problem:
ancient ruby version is shipped with enterprise

Version-Release number of selected component (if applicable):
1.6.8

How reproducible:
Always

Steps to Reproduce:
1. write a ruby program
2. know it will not work when update is made from 1.6.8 to 1.8.x
3. be sad. ;-(
  

Additional info:


i'm unclear why such an ancient version (it's __years__ old) of ruby is shipped with enterprise and it hinders ruby development.

can anyone shed light on this?
Comment 1 Kirk Haines 2005-10-12 14:30:16 EDT
I'll second all of these comments.  My servers run on RHEL.  98% of everything I write for my 
customers is written in Ruby, but 1.6.8 is unacceptable for my work, so I am forced to install and 
maintain my own Ruby installation instead of using RedHat's tools to manage this.  In my case this 
is simply a minor inconvenience, but in an environment where the freedom to simply install a 
package manually isn't allowed, being limited to Ruby 1.6.8 dramatically reduces the universe of 
Ruby software that can be ran on the machine, and there is no stability or security related reason 
for it. 
 
Ruby's version is currently at 1.8.3; 1.6.8 was left behind a long time ago. 
Comment 2 joe.vandyk 2005-10-12 14:49:50 EDT
Same problem here.  Really wish EHEL would ship with Ruby 1.8.2 or 1.8.3.
Comment 3 Akira TAGOH 2005-10-12 20:30:10 EDT
Unfortunately we, Red Hat doesn't currently plan to provide a resolution for
this in a Red Hat Enterprise Linux update for the deployed systems of this
release.  With the goal of minimizing risk of change for deployed systems, and
in response to customer and partner requirements, Red Hat takes a conservative
approach when evaluating changes for inclusion in maintenance updates for
currently deployed products. The primary objectives of update releases are to
enable new hardware platform support and to resolve critical defects. you know
that some features are obviously incompatible between 1.6.x and 1.8.x. so we
wouldn't take such risk. if you really want/need it, we'd recommend to upgrade
your systems to Red Hat Enterprise Linux 4 that we've already shipped ruby 1.8.x.

Thanks,
Comment 4 ara howard 2005-10-12 21:46:59 EDT
no offense - but this is astounding bad logic.  no one is suggesting you abandon
or replace 1.6.8 - merely that redhat maintain reasonably up2date versions of
the software rpms it provides.  (btw, 1.6.8 has a list of 'critical defects' a
mile long of which i'm sure you are aware.)  in any case, there is no good
reason not to provide a binary named 'ruby18' in /usr/bin.  it's no good
maintaining stable software that's old and obsolete - no one wants to pay for
that.  the approach i'm suggesting extends to newer versions as well, i'd expect
release 4 to support ruby 1.8.x as ruby18 and, relatively soon after it's
release, ruby 2.0 as ruby2.    there seems to be some precedent for this as i
find a python, python2, and python2.2 on my system here.  in any case, our
transition to fedora is mitigating this somewhat - but i thought you might be
interested in our rational, which is that enterprise has just as many
__serious__ bugs

  https://bugzilla.redhat.com/bugzilla/long_list.cgi?buglist=141996
  https://bugzilla.redhat.com/bugzilla/long_list.cgi?buglist=124626

costs money, and runs obsolete software.  it for these very reasons many of the
cluster managers in our building are moving to fedora or suse.  i sincerely
think it's in your best interest to adopt a stance that provides both stability
via known packages __and__ ability via somewhat recent releases.  the concept of
running stable software by using only old versions is completely at odds with
the open source model - indeed, many developers of popular open source products
(nfs for example) won't even take your bug reports seriously if you have
installed via rpm.

you can take our advice or leave it - but as it stands the up2date system is of
little use to us with exception of core system packages and i'll continue to
compile all the software i use for development by hand.  it would be great if
enterprise became more developer friendly and i hope you might forward these
desires.

regards.

-a


Comment 5 Akira TAGOH 2005-10-17 02:50:57 EDT
Well, I didn't yet mention about "why such an ancient version (it's __years__
old) of ruby is shipped with enterprise and it hinders ruby development.".
because when ruby-1.8.0 was released, it was too late to include it in the product.

If you think that you need that idea like ruby18, please go through the official
support way.  For official Red Hat Enterprise Linux support, please log into the
Red Hat support website at http://www.redhat.com/support and file a support
ticket, or alternatively contact Red Hat Global Support Services at
1-888-RED-HAT1 to speak directly with a support associate and escalate an issue.

Thanks,

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