On 28/05/08 at 19:01 -0000, Neil Wilson wrote: > On 28/05/2008, Lucas Nussbaum <[EMAIL PROTECTED]> 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 PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | -- Add rubygems bin to PATH https://bugs.launchpad.net/bugs/145267 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
