You can install gems from debian packages which _cannot_ put things into /usr/local/. You can also install gems directly. This would probably be a nightmare to maintain.
In my personal opinion the /var/lib path is broken too. The problem with the "language-centric" repositories and their client-side package managers is that they have to clash with the system packager. They clash for filesystem namespace (apt-get/yum install foo vs pip/gem install foo) and clash for semantics (one-vs-more-than-one version at a time). A suboptimal solution (at least for ruby where you _want_ to install many versions of one thing at a time) that would still improve the situation could make this: * work on rubygems to have a debian-connector that automatically keeps the debian metadata in sync (so packages installed via gem behave the same as packages installed with dpkg, except that they don't pick up non-ruby dependencies). * install things into /usr/lib and /usr/bin If anyone is willing to try doing this (the same debian-connector, or perhaps dpkg-connector) could be used for python and pip as well) feel free to start discussing and drafting this here. I was considering doing this a while ago. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/706603 Title: gem1.9.1 doens't install executables on PATH -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
