Folks, I'd agree that pre-packaging rails is desirable, in spite of the fact that it's easily installable using gem.
Native packaging vs gems has been a very hot(and sometimes vitriolic) topic with Debian and FreeBSD. If we go down the native packaging path, we'd certainly not have time to putback in the given time frame. On Matt's suggestion of bundling gems, and a packaging script - I'm open to trying that out, if that would get us past ARC and into Nevada. If that(or another quick idea) doesn't work, this(Ruby library packaging for Solaris) should be the next investigation that we take on, after we bundle Ruby + extensions. Cheers, -ps Brandorr wrote: > On 10/2/07, *Matt Ingenthron* <Matt.Ingenthron at sun.com > <mailto:Matt.Ingenthron at sun.com>> wrote: > > Brandorr wrote: > > On 10/1/07, Prashant Srinivasan <Prashant.Srinivasan at sun.com > <mailto: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.) > > > > I'd have a concern with #4. We've heard the opinion expressed > multiple > times that in emerging markets, like parts of China and India, not > including something with the OS distribution can be a major barrier to > adoption. We may be able to ignore this 'for now', but can't really > leave it alone very long. > > > . (Almost all rails tutorials will have you run "gem install rails" > first anyway.) Stick to just Ruby, gems an docs as the three first > packages to implement. > > > There are > > Is it possible to strike a balance by recommending regular gem > install, > but including a package that bundles common gems and an install > script? > This obviously isn't ideal and we'd need to think through patching. > > > Let's start with less, and add if there is a strong need. > > From my perspective, we need to both include common gems and somehow > support using the regular network repository gem install. In > conversation, I've also heard Jason Hoffman of Joyent agree with > Brandon > on the idea that the preferred way to install things like rails is > as a > gem, so there seems to be convergence on that idea. > > > Find me one rails developer that supports something other then gem > based installs. > > Prashant/Jyri: is there a good way to balance all of these? > > > Packaging up gems in an OS package manager kinda goes against the > whole philosophy. > > > - Matt > > -- > Matt Ingenthron - Web Infrastructure Solutions Architect > Sun Microsystems, Inc. - Global Systems Practice > http://blogs.sun.com/mingenthron/ > email: matt.ingenthron at sun.com > <mailto:matt.ingenthron at sun.com> Phone: 310-242-6439 > > > > > -- > - Brian Gupta > > http://opensolaris.org/os/project/nycosug/ > ------------------------------------------------------------------------ > > _______________________________________________ > 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
