Comment 44 for bug 145267

2008/8/12 Mathias Gug <email address hidden>:
> How so ?

In that the alternatives system will support and switch between
another two sets of binary wrappers once we write the packages.

> Are these no longer required ?

08 exists. All the other patches have been superceded. I've put the
details in the changelog.

>
> ===
> You should merge the latest version of debian (-2) as your package is
> currently uninstallable on intrepid.

Done.

> While testing the package I came across the usage of gem libraries:
> according to the rubygems documentation, you need to do some
> post-install work in order to setup ruby gems correctly. I was wondering
> if the ruby libraries could be symlinked to
> /usr/local/lib/site_ruby/RUBY_VERSION/ when a gem is installed ? That
> way you wouldn't have to modify your environment or call ruby with the
> -rubygems option. Since site_ruby is already versioned
> update-alternatives is not needed in that case.

The rubygems documentation is somewhat out of date. The way you use
libraries in a rubygem is simply to do

require 'library'

or if you want a particular version

gem 'gemname', >=2.1.0
require 'library'

Rubygems monkey-patches the ruby require system so that you get the
correct gem library automagically. It even works most of the time.

Have you an example that doesn't work like that?

> I've also come across the following situation:
>
> $ sudo gem1.8 install rails
> $ sudo gem1.9 install rails
> $ sudo gem1.8 install rails
>
> However /usr/local/bin/rake is still using ruby1.9. So gems dependencies
> are not switched to the ruby version used by the installed gem. Is this
> a valid use case ? How should it be handled ? Could the slave option of
> update-alternatives be used to handle binaries from dependencies ?

That's either a bug or a feature depending upon your viewpoint and is
merely a function of the way gem does reinstalls and handles
versioning (ie it reinstalls the requested gem, but not its
dependencies). If you do that with a source installed gem system, you
would get precisely the same result.

For me its an edge case with no easy win (the list of binaries of all
the dependencies is not readily available in the program).

Gem's dependency mechanism is primitive and it does get itself in a
mess if you do anything wildly unorthodox - like uninstall or
reinstall things :-). For this cycle I'd be happy if gem puts its
binaries on the system path and doesn't leave junk lying around or
break things when uninstalling stuff.

Do you consider this a show stopper?

I'll get a new version of the package into the PPA just as soon as
Intrepid lets me build one!

--
Neil Wilson