On 10/2/07, Matt Ingenthron <Matt.Ingenthron at sun.com> wrote: > > Brandorr wrote: > > 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.) > > > > 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 Phone: 310-242-6439 > > -- - Brian Gupta http://opensolaris.org/os/project/nycosug/ -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/webstack-discuss/attachments/20071002/b9f83965/attachment.html>
