Prashant Srinivasan wrote: > > Given that rubygems support in Solaris is already present, we have three > options to support Rails(and other gems). > > (1) Use Solaris packaging exclusively(ie., gems not allowed). > (2) Get Solaris and Rubygems to co-exist. > (3) Use Rubygems exclusively. ie., don't bundle Rails.
As you say, (1) isn't at all a realistic option. #3 is cleanest and easiest. But is it adequate? Some thoughts.. The ease of installation isn't any different: "gem install rails" vs. "pkg install SUNWrails".. not much there. Ease of finding it.. depends on the audience. For someone used to managing the system via pkg it's probably easier to stumble upon the package than to know about gem. But really, it's the Rails developer you're after here - and they sure know gem (more than they know pkg). Supportability. If(?) you're planning on supporting Rails, having the package is good since you need a known/fixed set of bits to support. Offline installations. Some environments (typically for security concerns) may only allow installations from official media, so online gem install would be out. pkg install too of course, but if there is a package it's possible to build a DVD containing it. Realistically that kind of environment is probably not the target market for Rails, but worth a thought. [But you could bundle the gem in the DVD as well, just not as conveniently.] I'd lean towards starting with #3 (via gem only) until there is concrete demand for a package. On the other hand, I remember that's what we said last time and now you're looking into Rails, so it's very possibly concrete demand already showed up, which is why you're here.. > We're left with the possibility that files packaged by Solaris will be > updated by gems if an end user decides to use Rubygems. This option is not an option. There can't be two supported mechanisms (packages & gem) stomping on each other modifying the same files. Only one delivery mechanism can own a given file. If you decide on packages, it needs to be done in a way that achieves #2 (peaceful coexistence). Debian seems to have achieved this so no reason OpenSolaris can't. gem-installed content goes under /var, package-installed content goes under /usr and they seem to coexist ok (I've played a fair amount with gem vs. packages on debian, but only at a shallow level. I urge you to experiment with it in more depth). > >Does this create any dependencies to MySQL and/or Postgres packages? > > Yes, it does. I'll update the imported interfaces list in the ARC case. So does it mean the SUNWrails package now depends on both MySQL and Postgres? Those are big components, there is no reason to demand that the user must install both if they want Rails (since typically they'll use one or the other, not both). Can these be separated into separate units, such as how PHP does it? (SUNWphp524-mysql vs. SUNWphp524-pgsql) -- Jyri J. Virkki - jyri.virkki at sun.com - Sun Microsystems
