Jyri Virkki wrote: > I'm summarizing from the thread (with a few additions): > > - Ruby users (and tutorials, books, etc) often assume installation via > gem, so we definitely do want this to work in Solaris, whether it's > the only way or not. > Agreed. > - AIUI default gem installs somewhere under /usr - that won't work due > to read-only filesystems, zones. >
Both the location of the gem installation and the gem repository can be customized. What are Solaris guidelines for libraries that might reside in /usr, but can't because they need to be modifiable through zones? If we follow Apache's htdocs precedent, gems should probably go into /var. > - It is also vital to support offline installs. > agreed. > - OTOH gem already does since it can read local *.gem files. > Yes. > - Ignoring location problems, does "gem install -r foo" work today for > all/nearly all gems on Solaris? (If no, that largely forces your hand > into delivering packaged gems, modified to work. But hopefully answer > is yes.) > The answer is yes.(Some gems have native dependencies and those need compilers in the users path gcc or studio). > - Are gems invalidated by any ruby update? Well, gems do have a "required_ruby_version" field. I've seen Mongrel use it. It's not used in rails - this does not mean that rails will continue to run without changes regardless of Ruby version, of course. > If a system has SUNWruby + > set of gem-installed code and they run update SUNWruby (say, via indiana > repository), what happens to all the (non-pkg-aware) gem code > They may or may not work depending on the gem(if we transparently increase the ruby version from under them), since they may not be intended for use on the new version of Ruby. Now, if we want to mitigate that problem, we could have the next-rev-ruby-pkg-installer check to see if rubygems is installed, if yes, backup existing gems, upgrade ruby, and then attempt to reinstall the older gems. if we do that, gems that are not designed for the new version(and declare that) will explicitly fail(rather than throwing a runtime exception). There is one problem though, the next-rev-ruby-pkg-installer needs to know if the currently installed rubygems will work with it, else it would need a rubygems upgrade to be in place. And if the rubygems upgrade needed the new version of ruby . . . we're in a catch-22. Or does Solaris packaging help here? Thanks, -ps -- Prashant Srinivasan F/OSS Enthusiast Sun Microsystems, Inc. http://blogs.sun.com/prashant GnuPG key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x82FBDE5A
