Comment 23 for bug 145267

On 28/05/2008, Lucas Nussbaum <email address hidden> wrote:
> That would require hacking rubygems quite deeply. If rubygems provided
> some hooks that we could use to implement distro-specific stuff, why
> not. But it's not the case, AFAIK.

Not really. It's a relatively straightforward program to follow and
Eric is quite helpful really. I don't perceive a big issue in getting
gem to issue the appropriate 'update-alternatives' command. To be
honest it could probably do with a pre/post hook system.

> What is the problem with installing to /usr/local/bin? It's in the
> default system path, and it's before /usr/bin and /bin.

That's one problem. gem installed systems would then override apt
installed systems and I'm not sure that is where we want to go.

> > That way it would work with gem1.9 as well. Apt packages could
> > override with a higher priority.
>
> If we install to /usr/local/bin, and you gem1.9 update --system, you
> will get a new gem executable in /usr/local/bin, that will "override"
> (by precedence in the path) Debian's.

You mean 'gem1.9 update' (gem1.9 update --system updates rubygems and
should be disabled)

Do we want that? If you install an apt package shouldn't that be the
one the system uses (from a stability point of view).

The problem I see is when gem1.8 and gem1.9 are on the same system. If
you install a gem in 1.8, then install it in 1.9 a remove in 1.8 will
remove the 1.9 binary in /usr/local/bin

--
Neil Wilson