On 9/28/07, Jyri Virkki <Jyri.Virkki at sun.com> wrote: > Prashant Srinivasan wrote: > > > > We proposed Ruby and Rails to coexist in the same package. This is > > I don't like that idea much. A package should deliver one unit of > functionality. Ruby can be used without Rails so these are logically > independent. > > Thinking longer term, we'd like to see the "Indiana" package > repository to be as rich as, say, Debian's. Do you propose that all > ruby modules be delivered in that single ruby package? Rails might be > one of the most popular but it is not the only one. > > % gem list -r | wc > 6992 29255 222386 > > I didn't count but the descriptions seem to average about 5 lines, so > that's on the order of a thousand gem packages. Do they all eventually > go into SUNWruby? > > > > 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. > > Don't forget Indiana packaging is around the corner, need to plan > ahead for that, so installing these Solaris packages will be the same > one-liner we're used to with apt-get, yum, etc. > > > > 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. > > I don't see how the single vs. split packaging changes anything, can > you expand? If the user installs Rails from a Sun package (whether it > is the combo Ruby+modules package or by installing Ruby pkg & Rails > pkgs) and then tries to upgrade using gem, there's going to be > confusion either way (either overwritten or duplicate files, depending > on layout). > > Here's a topic IMO you need to address for the ARC proposal: should > you ship Rails at all, or just package Ruby + gems and get the rest of > the modules via gem (automated and/or manual)? Or ship supported > packages and discourage gem? Or adapt gem?
Personally, I feel that Gem should not be included in the Ruby package, there should be three packages 1) Ruby 2) Ruby documentation 3) Ruby Gems Rails would just get installed as a Gem. Anything else would be counter intuitive to users. > > (Also remember that /usr cannot be assumed to be writable, may be > read-only filesystem.) > > Here's some useful discussion from debian (see rubygems at the bottom): > http://pkg-ruby-extras.alioth.debian.org/rubygems.html > > > > -- > Jyri J. Virkki - jyri.virkki at sun.com - Sun Microsystems > _______________________________________________ > webstack-discuss mailing list > webstack-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/webstack-discuss > -- - Brian Gupta http://opensolaris.org/os/project/nycosug/
