On 10/1/07, Prashant Srinivasan <Prashant.Srinivasan at sun.com> wrote: > 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.
#4 vote here. (I would however that instead of strictly investigating #2, we move towards a verification process that tests for clean installation of the top 30+ gems, using "gem install", and only resort to option two in the event that a "gem install" can't happen cleanly.) > 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 > > > -- - Brian Gupta http://opensolaris.org/os/project/nycosug/
