Comment 25 for bug 145267

On 28/05/08 at 19:01 -0000, Neil Wilson wrote:
> 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.

See my other mail on the topic: update-alternatives won't work, because
you would have to modify all Debian packages that might provide the same
binary as a gem.

> > 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.

I think it is where we want to go: if an admin installs stuff manually,
that's probably because the things provided by the distro don't suit his
needs. So the distro stuff should be overriden by default.

> > > 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)

no, I meant --system. By "That way it would work with gem1.9 as well.",
I thought you meant "gem1.9 could be overriden as well".

> 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

By default, gem installs binaries to /usr/bin. The /var/lib/gems/.../bin
hack is Debian-specific, see the second part of
http://svn.debian.org/wsvn/pkg-ruby-extras/packages/libgems-ruby/trunk/debian/patches/01_default_gem_path.dpatch?op=file&rev=0&sc=0

So this problem (co-installation of gems with binaries for 1.8 and 1.9)
is a rubygems problem, not a Debian one.
--
| Lucas Nussbaum
| <email address hidden> http://www.lucas-nussbaum.net/ |
| jabber: <email address hidden> GPG: 1024D/023B3F4F |