Brian Gupta wrote: > I have been contemplating something... earlier I suggested that we > don't get into the business of wrapping up gems as SYSV OS Packages. I > still feel that this is probably correct. >
Hi Brian, Agreed. I think that it's a waste of time to "repackage" gems in general as Solaris packages(ie., we should avoid taking the path Debian took). IMO, if we could (1) include certain "core" components such that (2) upgradeability/removability through Rubygems is not affected, then we'll have a readily available set of these core components available in the OS (I'm thinking Rails) - while being in line with Rubygems packaging. I think the advantage for Nevada is in the "pre-availability" of popular software. Another reason is that Rubygems does not have an advanced notion of access control, so setting up user specific $GEM_HOMEs is not the easiest mechanism out there. ie., if you're not root, and want to install Rails, there are hoops. Not that this is specific to Solaris, but it's still an issue. > However, I thought that maybe we need to setup our own gem repository, > with precompiled and preconfigured native gems. What do you guys > think? > > Would we recommend this repository instead of the default gem repository that rubygems connects to, and then mirror the default repository? How would that be advantageous? -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
