On 5/26/06, James Britt <james_b / neurogami.com> wrote:
>
> Interesting.  I had thought there were well-defined locations for
> different types of libraries (core, stdlib, and everything else),  so
> that replacing old with new would be predictable (e.g., an upgrade could
> just nuke any old core + stdlib stuff and drop in new ones, leaving any
> custom stuff alone).

The openssl example is a prime deal breaker. To fix this problem you
must either selectively delete the old openssl stuff in site_ruby, or
delete the entire site_ruby. The first solution could become a
maintenance nightmare because every time something moves from
site_ruby into the stdlib we would have to add a special case for it
to the installer. The second solution is bad because then the non-gem
libraries that are installed will be deleted, which I guarantee people
will not like.

With our current solution we are being explicit that you're old ruby
install will be uninstalled first, so at least you know what you are
getting into.

> A job for Rake or Reap or Rant ...

To me that sounds like RubyGems could use some improvements...like
maybe bulk installs, or a nice point and click GUI (click all the
checkboxes for the gems you want.) In fact now that I've thought of
this I'm surprised no one has coded that up.

Ryan