On 23 Oct 2007, at 16:50, Austin Ziegler wrote: > On 10/23/07, Laurent Sansonetti <[EMAIL PROTECTED]> wrote: >> In Leopard, we didn't want to use a unique gem repository, because we >> wanted to separate the pre-installed gems that ship with Leopard from >> the gems that the user will install after. So Leopard comes with 2 >> gem >> repositories, one inside the Ruby framework that contains all the >> pre-installed gems, and another one in /Library which is empty by >> default, but which is also the default repository. > > What happens if I upgrade a gem? This seems relevant to the discussion > that's been happening here with respect to Linux distros wanting more > from both Ruby and RubyGems. Is there something that can be > generalized here for either and/or both?
I'm looking at this same sort of thing for Debian / Ubuntu. In my case, I want to do app server deployments (i.e. deployments of app servers, rather than deployments to app servers...) so I want everything nailed down and deployed using OS packages I reckoned I'd get something that worked for me and then see what people thought, but since there seems to be discussion around here.... I'm using Gem::Installer and some of the Gem::RemoteInstaller internals to fetch, snaffle information from a gem in order to build the dpkg standard directory structures, and then 'install' the gem into the tmp dir that acts as a sort-of fake /. It's not pretty (yet), and if people liked some of the approach then we'd need to tighten up the interactions between my code and Rubygem's internals... My main pain points so far have been building a tarball containing the .gem, and persuading Gem::Installer that it should put binary wrapper scripts in tmp/usr/bin rather than symlinks somewhere else... I was also wondering about a two-level split between gems, much like / usr/lib /usr/local/lib, much like the /System/Frameworks /Library/ split you have with MacPython and with what Laurent seems to have done with Ruby in Leopard. I shall follow this discussion with interest and make my stuff available when it's not quite so embarassingly quickly-sketched- prototype Best, Matt -- Matt Patterson | Design & Code <matt at reprocessed org> | http://www.reprocessed.org/ _______________________________________________ Rubygems-developers mailing list [email protected] http://rubyforge.org/mailman/listinfo/rubygems-developers
