From: Austin Ziegler Date: 2007-11-22T21:38:02+09:00 Subject: Re: RubyGems 0.9.5 On 11/22/07, Michael Greenly wrote: > Using environment variables to override locations makes sense for end > users but not for base system configuration. Either using a file in > rubylibdir or a value in rbconfig both seem like excellent choices. Or > better yet using all these methods in an ordered evaluation seems the > best choice. Disagree re: environment variables. There are exactly two environment variable schemes that have to be patched: export FOO=bar set FOO bar This can be done with /etc/profile or whatever the equivalent for csh is. (On Solaris there's an even better place in /etc, but I can't remember what it is.) Patches for a rubylibdir support file would be good to offer to the RubyGems team. > The one thing I keep sticking on is how do you handle 'gem update > --system' > Assuming that RubyGems is installed initially through a a distro package > it obviously can't update it's self in place. I think the ideal > solution here is that RubyGems (through load paths) allowed for two > levels of installation. Not good, won't work. > What I mean is if the Debian distributed RubyGems was initially > installed right along side Ruby but an 'update --system' caused it to > install the new version to some none-dpkg controlled directory (that had > load order precedence) everything would mostly work as expected. Bad. Special case for a mere distro. > It's not a perfect solution. There's the potential for users to get > confused about which RubyGems is getting used but they can check using > 'gem environment'. Potential defined as near-100%. > Is this at all what Apples patch did? or was that just for the gem > location? Just for the gem location. With instructions on how to update the RubyGems installed on the system. In other words, Apple didn't expect you to wait for an OS update to update RubyGems, and it doesn't have fine-grained package management like most Linux distros (which is both good and bad). Downside right now to the Apple approach is that it's unclear what will happen if you upgrade to RubyGems 0.9.6 (doesn't yet exist) but the next OS X system update has RubyGems 0.9.5. I'd hope that Apple's software checks the difference, but nothing has been said about that so far. If Debian doesn't want you updating RubyGems outside of Debian -- which is acceptable if not desirable, disable system updates outside of apt-get. Just stop bastardizing the rest of RubyGems and do it right. Otherwise, Debian needs to be ready for people to update RubyGems in the system location using RubyGems itself and handle that correctly on future apt-get updates. Having two copies of RubyGems isn't really going to be a good choice, especially with RubyGems moving into core Ruby with 1.9.1. -austin -- Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/ * austin@halostatue.ca * http://www.halostatue.ca/feed/ * austin@zieglers.ca