On Mon, Dec 8, 2008 at 7:23 PM, Richard Laager
<rlaager@wiktel.com> wrote:
On Sat, 2008-12-06 at 18:17 +0100, Lucas Nussbaum wrote:
> On 06/12/08 at 10:44 +1100, Nic Williams wrote:
> > Hey everyone, (please reply-all or cc: me)
I would imagine this would end up being a tree of symlinks pointing at
the FHS locations. This would be in GEM_PATH (which doesn't necessarily
need to be setup as an environment variable per se; it could be patched
in to the rubygems code). You'd continue to have GEM_HOME point
to /var/lib/gems (or wherever it is now), which would also be in
GEM_PATH.
Thus, if a gem is installed system-wide via APT/dpkg, it will Just Work.
However, if you install a gem using "gem install ...", that'll Just
Work. Imagine these scenarios:
1. Richard wants to provide a number of common gems on his web servers
for use by customers.
2. Bob, a customer of Richard's, needs a newer version of a gem than is
installed system-wide. He wants to be able to drop a newer gem into his
vendor dir and have it override the system-wide version for his website.
3. A security bug is found in a gem that Bob is using and Richard wants
to install an even newer, patched version system-wide and have it
override Bob's version.
This functionality already exists with apt. Plus, with apt, you also get system-wide security notification, not just about gems or ruby.
4. Richard wants to provide a gem system-wide that is not packaged in
Debian. He'd like to type "gem install FOO" and have it Just Work (until
he can package the gem for Debian himself).
I'm not sure that all of these work well right now. They would if Debian
were installing (which, as I said, may mean symlinks) the gems *as
gems*.
There is at least one major issue: how do you install system dependencies in this scenario? You assume that all anyone wants to install are gems, while actually people want, and have to, install other libraries as well. Sometimes these libraries are needed by ruby, like libgd for example. You cannot expect people to install libgd as a gem. So the logical thing would be to make ruby conform to the leading package management tool for linux: apt
apt is much more powerful than the ruby mechanism because it understands system level dependencies, not just ruby dependencies. These is needed when you are building a distribution and not just a collection of ruby libraries.
I recommend re-reading Lucas' mail about packaging ruby for debian and try to find a way to incorporate ruby in the debian model, as opposed to the other way around. Users will be grateful for an easy way to install ruby gems as well as their dependencies and not have to suffer through dependency hell, which is so 1996.
Jeremiah