> I'd imagine you should deliver a ruby package and a separate RoR rails package (which depends on ruby).
We proposed Ruby and Rails to coexist in the same package. This is because Ruby has a network-based package management system which is very easy to use compared to our packaging. Once you have rubygems(which we're bundling along with Ruby). You can upgrade your Rails installation with it(one line command, similar to the blastwave pkg-get) without having to go through the relatively tedious process of installing a Solaris package. So, if Rails is delivered as a separate package, the end user, when s/he wants to upgrade rails, will bypass the Solaris packaging(and use the Ruby gems packaging mechanism) which will result in a rails installation which is a different version than the version that our package advertises. Do we see this side effect as a problem? If yes, I'd venture a single package for Ruby and Rails, such that end users can upgrade rails using rubygems. They would only need to upgrade our Ruby package when they come to the point where their rails or other infrastructure needs a new Ruby build. Else, lets split into Ruby and Rails. What do you think? thanks, -ps Jyri Virkki wrote: > Prashant Srinivasan wrote: > >> Why "ruby" in the directory name, as opposed to Ruby-On-Rails, or RoR? >> > > ruby seems appropriate for ruby ;-) > > But more to the point, Rails is a separate unit, ruby exists > independently of it. One can certainly be a ruby user without ever > using RoR. > > I'd imagine you should deliver a ruby package and a separate RoR rails > package (which depends on ruby). > > > -- 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
