installing `ruby2.0` results in ruby 1.9.3-p484 as default version

[Joshua Timberman]

I expected that installing the "ruby2.0" package explicitly, I would get ruby 2.0 as my default version. However, due to the dependency tree of the ruby2.0 package, version 1.9.3-p484 is the default version instead.

ubuntu@ruby20:~$ apt-cache depends ruby2.0
ruby2.0
  ...
  Depends: ruby

ubuntu@ruby20:~$ apt-cache depends ruby
ruby
  Depends: ruby1.9.1

ubuntu@ruby20:~$ sudo apt-get install ruby2.0
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
  ca-certificates libjs-jquery libruby1.9.1 libruby2.0 libyaml-0-2 openssl ruby ruby1.9.1 rubygems-integration
Suggested packages:
  javascript-common ri ruby-dev ruby1.9.1-examples ri1.9.1 graphviz ruby1.9.1-dev ruby-switch bundler
The following NEW packages will be installed:
  ca-certificates libjs-jquery libruby1.9.1 libruby2.0 libyaml-0-2 openssl ruby ruby1.9.1 ruby2.0 rubygems-integration
0 upgraded, 10 newly installed, 0 to remove and 104 not upgraded.
Need to get 0 B/6,377 kB of archives.
After this operation, 28.2 MB of additional disk space will be used.
Do you want to continue? [Y/n]
....snip

ubuntu@ruby20:~$ which ruby
/usr/bin/ruby
ubuntu@ruby20:~$ ls -l /usr/bin/ruby
lrwxrwxrwx 1 root root 9 Feb 14 21:22 /usr/bin/ruby -> ruby1.9.1
ubuntu@ruby20:~$ ruby --version
ruby 1.9.3p484 (2013-11-22 revision 43786) [x86_64-linux]

[Joshua Timberman (jtimberman)]

It appears upstream (Debian) Ruby package changed this during the Trusty freeze:

ruby-defaults (1:2.0.0.1~exp3) experimental; urgency=medium

  * ruby-all-dev: migrate from Ruby 1.9.1 and 2.0 to Ruby 2.0 and 2.1
  * ruby: remove Breaks/Conflicts/Replaces against old interpreter packages
    as this will force the removal of old interpreters from users' systems
    (Closes: #740733)
    .
    The following upgrade scenarios from wheezy were tested, still work fine,
    and leave the old interpreters alone:
    - ruby
    - ruby + ruby1.8
    - ruby + apt-listbugs
    - ruby + ruby1.8 + apt-listbugs
    - ruby1.8 + apt-listbugs

 -- Antonio Terceiro <email address hidden> Sat, 29 Mar 2014 16:12:05 -0300

Is it possible to integrate these changes into Ubuntu so that the package installation behaves as a user expects? I can't imagine anyone who wants "ruby2.0" would expect ruby 1.9.1/1.9.3-p484, especially as the default version.

Yes, update-alternatives is a thing, but this is an extra step which should not be necessary.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[[e-mail] (gwaldo)]

Truth is spoken here. If I install Ruby2.0, that's what I expect to have readily available.

[Dusty (8-ubuntu-g)]

I agree that I expect ruby2.0 to be the only version installed and at the least the default version.

It appears update-alternatives no longer supports ruby out of the box as well.

# update-alternatives --config ruby
update-alternatives: error: no alternatives for ruby

It also seems strange to me that this package installs libjs-jquery.

The following extra packages will be installed:
  libjs-jquery libruby1.9.1 libruby2.0 ruby ruby1.9.1 rubygems-integration

What does jquery have to do with ruby?

[Chris Hofstaedtler (zeha)]

From the Debian POV, this is working as designed.

If you install ruby2.0, it is available as ruby2.0.

[Joshua Timberman (jtimberman)]

Are you kidding me?

In what possible scenario would you NOT expect "apt-get install ruby2.0" to give you ANYTHING but ruby version 2.0(dot whatever) as the default Ruby interpreter?

This is broken.

[Joshua Timberman (jtimberman)]

To clarify: it should make the default `ruby` point at Ruby 2.0. If this is a bug in update-alternatives, then so be it. It is absurd to me that this was closed invalid when it doesn't do the thing that a user would expect.

[Joshua Timberman (jtimberman)]

Furthermore, this is fixed in the Debian package! Ubuntu 14.04 was past "import freeze" when the package was fixed. It should be implemented. Seriously.

[[e-mail] (gwaldo)]

Expected behavior is not delivered.

If I ran 'apt-get install apache2' and found that apache1.x was installed instead, I'd be upset.

[Paul Graydon (twirrim)]

"From the Debian POV, this is working as designed."

If that's the case, why did Debian consider it a bug and fix it upstream? You've got me very confused.

[Chris Hofstaedtler (zeha)]

You're probably misunderstanding how this works in Debian, let me explain:

Installing ruby1.9.1 gives you /usr/bin/ruby1.9.1.
Installing ruby2.0 gives you /usr/bin/ruby2.0.
Installing ruby2.1 gives you /usr/bin/ruby2.1.

The "ruby" package is merely a package that points /usr/bin/ruby to one of those from above; installing ruby2.0 or 2.1 doesn't change where /usr/bin/ruby points to.
This is similar to the python packages.

Now 14.04 apparently froze at a time where jessie was in the middle of the transition from 1.9 to 2.0. (A similar thing would apply today: jessie already has ruby2.1, but /usr/bin/ruby is still 2.0.)

I don't know if Ubuntu has dedicated resources to ruby or not, but I doubt they can still change this for 14.04.

[Matthias Klose (doko)]

> I don't know if Ubuntu has dedicated resources to ruby or not,
> but I doubt they can still change this for 14.04.

no, we don't have, and it won't be changed for trusty. fixed in utopic. if you are interested in getting ruby to a recent version for future releases please consider working with the Ubuntu developers, starting way ahead before a possible release date.

[Matthias Klose (doko)]

fixed in utopic

[Matthias Klose (doko)]

won't fix for trusty

[[e-mail] (gwaldo)]

Sorry, could you dumb this down a notch for me?

I get that when I request "ruby2.0" you have $REASONS for also installing 1.9.fuckingancientwhocares

What I fail to understand is how not making THE THING I REQUESTED the default.

[Joshua Timberman (jtimberman)]

I understand quite well how package management works in Ubuntu and Debian. Over the past 5 years I've packed a number of Ruby projects (such as Chef and its dependencies) for Debian and Ubuntu. I guess that's why this problem irritates me so much: I thought we were finally having progress to get sane Ruby versions as defaults.

Anyway, okay, my installation of `ruby2.0` means I have to run `/usr/bin/ruby2.0`. Fine. The `update-alternatives` system isn't aware of Ruby, and I have to make symlnks myself. Fine[0].

However, let me explain why I think this is still broken.

`ruby2.0` depends on `ruby`. `ruby` depends on `ruby1.9.1`. Thus, `ruby2.0` depends on `ruby1.9.1`. This dependency graph is fundamentally flawed: ruby2.0 does not in any way, shape, or form depend on ruby1.9.1. Having two separate interpreters and stdlibs installed on the system at one time, when only one was specifically requested for install is asking for trouble.

I get that Ubuntu doesn't want to do the work to make /usr/bin/ruby -> /usr/bin/ruby2.0, fine. But don't bring in the `ruby1.9.1` package when I install `ruby2.0`. Debian fixed this. Why won't Ubuntu? Is it the "DebianImportFreeze"? I think that's a lousy excuse. Other patches are brought in (such as security fixes). Is it a "not enough people/resource" issue? if Ubuntu doesn't have available resources to ensure obvious user-facing bugs like this are fixed in the Ruby interpreter for long term support releases, then I suggest that Ruby be dropped from "main" (to universe, I guess?) and the reality of "you're on your own" be made explicitly clear for any users who want to have Ruby on Ubuntu.

[0]: https://gist.github.com/jtimberman/1c9cfee514644a04f9c2

[Saku Ytti (ubuntu-ip)]

What does "Won't Fix" mean for this LTS release?

Does it mean, there will not be, for lifetime of LTS, anyway 'ruby' would call version 2.0? If you want that to occur, you need to mangle symlinks yourself?

Isn't this regression? As 'ruby-switch' package did this in 13.10?

Could solution be, to reintroduce 'ruby-switch'?

What are we afraid that fixing this problem might break? Who could desire+depend on this newly introduced behavior? What type of use-case?

[Daniel Muller (daniel-muller)]

The problem seems to be in the fact that "ruby2.0" depends on "ruby", which depends on "ruby1.9.1".
I rebundled the package without the dependencies to "ruby" and "rubygems-integration": https://launchpad.net/~spuul/+archive/ruby2.0

I removed the dependency to libjs-jquery too (I am unclear why this dependency exists) and added the alternatives symlinks.

Is there a way to provide a trusty-updates for this package? I am unclear how this would work.

[[e-mail] (gwaldo)]

That Ruby2.0 depends on Ruby1.9.1 isn't as much the problem as the fact
that when Ruby2.0 is installed, it is not the default ruby; ruby1.9 is.
 That, to me, is completely baffling.

On Mon, May 12, 2014 at 12:10 AM, Daniel Muller
<email address hidden>wrote:

> The problem seems to be in the fact that "ruby2.0" depends on "ruby",
> which depends on "ruby1.9.1".
> I rebundled the package without the dependencies to "ruby" and
> "rubygems-integration": https://launchpad.net/~spuul/+archive/ruby2.0
>
> I removed the dependency to libjs-jquery too (I am unclear why this
> dependency exists) and added the alternatives symlinks.
>
> Is there a way to provide a trusty-updates for this package? I am
> unclear how this would work.
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (1313864).
> https://bugs.launchpad.net/bugs/1310292
>
> Title:
> installing `ruby2.0` results in ruby 1.9.3-p484 as default version
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu/+source/ruby2.0/+bug/1310292/+subscriptions
>

[agent 8131 (agent-8131)]

I ran into this today. I was surprised that the update-alternatives support for ruby had been yanked. Here's how to set ruby2.0 to be the default:

sudo ln -sf /usr/bin/ruby2.0 /usr/bin/ruby
sudo ln -sf /usr/bin/gem2.0 /usr/bin/gem

No promises this will work 100% or not cause problems with other installed ruby dependent software.

ruby -v

should produce:
ruby 2.0.0p384 (2014-01-12) [x86_64-linux-gnu]

gem -v

should produce:
1.8.23

[Aaron Stone (sodabrew)]

+1 for fixing this as a Trusty SRU. Keeping it broken for the next two years is completely ridiculous. Please PLEASE fix the ruby2.0 dependency error on Trusty.

The least-surprising thing to do is to change the package dependency error so that installing ruby2.0 does not pull in ruby1.9.1. People are just now planning their migrations to Trusty, and if they see this bug, then see it fixed, it'll be "oh cool, thanks for handling this bug in a sane way Ubuntu!"

[Aaron Stone (sodabrew)]

Link to SRU proposal: https://bugs.launchpad.net/ubuntu/+source/ruby-defaults/+bug/1315143

[stevenschlansker (stevenschlansker)]

I just stumbled on this, and if the Ubuntu team will close such obvious problems with "Won't fix" for a LTS release, they should IMO just be up front that it is not supported and remove Ruby packaging entirely. Leaving totally broken packages in doesn't help anyone.

[stevenschlansker (stevenschlansker)]

BTW, this is actually maybe a security problem too -- people who think they are installing a supported version are actually silently getting an unsupported version that no longer receives upstream security fixes: https://www.ruby-lang.org/en/news/2014/01/10/ruby-1-9-3-will-end-on-2015/

[stevenschlansker (stevenschlansker)]

Here is our workaround which should be better than the ones proposed above (doesn't get wiped out by package upgrade / reinstall)

# Rename original out of the way, so updates / reinstalls don't squash our hack fix
dpkg-divert --add --rename --divert /usr/bin/ruby.divert /usr/bin/ruby
dpkg-divert --add --rename --divert /usr/bin/gem.divert /usr/bin/gem
# Create an alternatives entry pointing ruby -> ruby2.0
update-alternatives --install /usr/bin/ruby ruby /usr/bin/ruby2.0 1
update-alternatives --install /usr/bin/gem gem /usr/bin/gem2.0 1

Can we get this issue re-evaluated / re-opened? IMO the "Won't Fix" assessment was premature, especially in the context of Ruby 1.9 being unsupported.

[Seth Arnold (seth-arnold)]

The ruby1.9.1 in 14.04 LTS is in main and is supported by the Ubuntu security team for the life of the LTS.

[Gerhardus Geldenhuis (gerhardus-geldenhuis)]

This really is a bug and baffling that it won't be fixed. We used 14.04 for the stability not the brokenness and having to go to 15.10 to get working ruby version that I don't have to manually symlink is not a great solution.

[George (slinkygn)]

"The ruby1.9.1 in 14.04 LTS is in main and is supported by the Ubuntu security team for the life of the LTS."

Is the Ubuntu security team providing out-of-band updates for Ruby 1.9.x? Because if not, it clearly is *not* being supported for the life of LTS -- 1.9.x is obsolete and isn't receiving security patches from upstream. Any security holes will remain holes, unless Canonical plans to patch them themselves.

(Related: that 1.9.x would be obsolete very shortly into the lifespan of Trusty was known three months before Trusty was released. https://www.ruby-lang.org/en/news/2014/01/10/ruby-1-9-3-will-end-on-2015/ Hindsight is 20/20, but making this a don't-fix on top of it having been a known security vulnerability less than a year into the cycle of an ostensibly LTS product prior to launch is almost unfathomable.)

The LTS wiki page describes the goals of LTS: limit feature set, so that maintaining and hardening the feature set that is included can be the primary criterion for releases. 1.9.x is inherently insecure -- and it is currently a *requirement* for installing 2.x? That should be unacceptable for an LTS build.

Perhaps if 2.x were a revolutionary change that fundamentally broke a majority (or even a significant minority) of existing code, the argument could be made -- but that is largely not the case. 2.x has been long enough, and reviews have come in from all over, to where we know that remarkably little 1.9.x code required changing at all, let alone any major revisions. And on top of that, you have manpower in the comment thread already that has volunteered to help build that transition. I'm happy to throw my name into that hat as well. I don't see how won't-fixing this, and not even *considering* its being fixed, can be seen as in any way compliant with the purpose of an LTS release.