On 08/12/08 at 10:23 -0800, Richard Laager wrote: > The outcome of the discussion we had is that we both feel that Debian > should install "gems" into a system-wide location--as gems. (Apple > apparently does this already.) Given that Debian has to follow the FHS, > 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. I'm not denying that it's a solution that would work, from a technical point of view. I also considered that myself. But for the user, that means having a packaging system with 2 layers, with APT over gem. And nasty interactions between them. For the Debian packagers, that means having to support those gems, even in Debian stable releases. Which is not going to be easy, since, for example, we would need a way to depackage/repackage gems to modify files in them. Also, I don't really like the idea of supporting software from people who don't want to help Debian in the first place by providing non-gem installation procedures. So, I think that the current solution (provide a rubygems package so users can install gems if they want to) is a better solution right now, both for the users and for the Debian packagers. But it doesn't fix the problem of packaging applications (web or not) that depend on gems. To solve that problem, we need the gems community to understand that we have different needs, and advocate that applications developers provide a non-gem setup procedure in addition to the gems procedure. Lucas PS: Please forget about the FHS. It's really the least of our problems here.
Attachment:
signature.asc
Description: Digital signature