Thanks much for the comments. Debian, and FreeBSD seem to have their own "ports" of ruby gems. It's not clear if these packages will can be detected by rubygems. With Fedora, Ruby and gems are available through yum. And rails is installed through gems.(Fedora also packages some libraries as rpms rather than gems, such as sqlite.)
For Nevada, I think we should support gem based install irrespective of whether we pre-bundle certain libraries, since users will need that to work(we cant possibly provide our ports to all the gems out there). On the issue of distributing software(rails, or mongrel etc). We have the following options: 1-> wrap Solaris packaging around "gem install --local" (problem: gem uninstall is not bound to pkgrm, and this can leave things in an inconsistent state). 2-> Create Solaris package versions of certain gems. Investigate what should be done for interoperability with gems(or decide to ignore interoperability with gems). 3-> Provide pre-installed gems with with the Ruby package(wont scale with time). 4-> Don't bundle them for now, since they're quite easy to install, and investigate #2. Comments? -ps http://pkg-ruby-extras.alioth.debian.org/rubygems.html http://www.freebsd.org/ports/rubygems.html http://legacy.not404.com/cgi-bin/trac.fcgi/wiki/RailsOnFC6 http://blog.sammorrison.com/2007/08/setting-up-ruby-on-rails-on-fedora-7.html Brandorr wrote: > 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 >> >> > > > -- 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
