The issue is that certain popular gems that are not entirely ruby code: e.g. - MySQL gem, fastthread, rmagic, etc. These gems need to be compiled. (If the compiler used to build rubygems is on the system, this is a relatively painless process for most gems, but not all. Since I am thinking Sun is planning to compile ruby with cc, the existence of this compiler isn't guaranteed. So that is one ease of use hurdle we need to overcome.
One option is to put precompiled gems in a repository. (Another would be to make sure whatever compiler you compiled rubygems with, ships with the OS) That then brings us to rubygems like rmagic and mysql that are linked to or wrap third party applications. When they are compiled they need to be configured. This can be intimidating to a Rails developer. (I recently had to go through these hurdles myself, and was surprised at how much sysadmin knowledge was required to get a ruby stack up and running. (By sysadmin knowledge I mean that you can recognize that it is calling cc instead of gcc, and know what that means) Please note my experience was with the Blastwave Ruby/rubygems build, which was built with cc. Cheers, Brian On Jan 16, 2008 12:01 PM, Prashant Srinivasan <Prashant.Srinivasan at sun.com> wrote: > 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 > > > -- - Brian Gupta http://opensolaris.org/os/project/nycosug/
