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