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
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 |
On 28/05/08 at 19:01 -0000, Neil Wilson wrote: alternatives' command. To be
> 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-
> 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 svn.debian. org/wsvn/ pkg-ruby- extras/ packages/ libgems- ruby/trunk/ debian/ patches/ 01_default_ gem_path. dpatch? op=file& rev=0&sc= 0
hack is Debian-specific, see the second part of
http://
So this problem (co-installation of gems with binaries for 1.8 and 1.9) www.lucas- nussbaum. net/ |
is a rubygems problem, not a Debian one.
--
| Lucas Nussbaum
| <email address hidden> http://
| jabber: <email address hidden> GPG: 1024D/023B3F4F |