FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.

» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Ubuntu > Ubuntu Server Development

LinkBack Thread Tools
Old 11-22-2007, 02:28 PM
Mathias Gug
Default RubyOnRails for Hardy (Was: Server Team 2007-11-20 meeting minutes)

Hi David,

On Thu, Nov 22, 2007 at 08:30:37AM -0600, David Portwood wrote:
> On Thu, 2007-11-22 at 11:32 +0100, Lionel Porcheron wrote:
> > https://wiki.ubuntu.com/RubyOnRailsStack
> >
> > * I think that the first thing we HAVE to avoid is people using gem (gem
> > is the internal ruby package manager). David is talking a lot of gem in
> > this spec, we can not afford people to use gem if we want to offer them
> > support. That should figure in the rationate IMHO.
> I don't see an issue with going non-gem for mongrel and rails, as long
> as Rails is relatively new 1.2.5 or better (which it is in Hardy). We
> just need to package a Mongrel Cluster to offer what people actually
> need.

This should be added to the Design section of the specification.

> This brings up the question do we rid ourselves of rubygems all
> together and package current offered gems?
> http://gems.rubyforge.vm.bytemark.co.uk/gems/ has a list of all current
> gems, I didn't bother counting, there are ALOT.

We have the same problems with python eggs (and easy_install), java
jars, php pear, perl cpan. These methods are interfering with the native
packaging system. The ideal is to be able to be able to install the gems
via apt. OTOH there are lots of them. So I wouldn't focus on trying to
get all the gems packaged for Hardy - that would require too much work
and testing.

However having a simple way to turn gems into debs would be a great
thing. Is there any project doing this ?

For more information on Debian position on rubygems, see

> The majority of rails developers have various gems installed on
> different rails apps, so maybe packaging gems isn't the right idea as we
> really have no way to tell the app the gem is installed as gems
> typically install into the rails apps dir.

So a gem is part of the application rather than part of the system ?
(similar to a static versus dynamic libraries ?). If that is the case,
packaging gems is not that important if end user ship their own gems

> > * It looks like people are now using a lot Mongrel for rails deployment.
> > The biggest problem with Mongrel is that a mongrel instance is needed
> > for each rails application. This means we have to make a lot of
> > configuration.
> Its really just a single file, symlinked from /etc/mongrel/ into the
> rails apps config/ dir, thats why I thing we should have a sample app
> installed, it gives the user a good POV into the setup of an app.

Agreed. That should be documented (which should be added as a point in
the implementation section of the spec).

> > * I have looked on several wiki pages for what is written on RoR
> > applications deployment, looks like fcgid can still do the work (I
> > personally use fcgid on my rails deploys). Here is the tuto on h.u.c:
> > https://help.ubuntu.com/community/RubyOnRails#head-4085777ac71d17a335ae30467137a05e8950883a
> > * I would not personally take care of postgresql, 99,9% of people who
> > use RoR use MySQL.
> The majority of the rails community frowns upon fcgid (apache mod_fcgi)
> its performance is less than stellar.

Which fastcgi implementation are talking about ? libapache2-mod-fcgid or
libapache2-mod-fastcgi ?

One point of the WebAppsPackaging spec is to move libapache2-mod-fcgid
to main as the preferred choice to server web applications.

What is the other option you recommend for a RoR stack ?

> > One thing we have to be aware, is that RoR is evoluding very fast.
> > People often want the latest and greatest release. I'm not sure how (and
> > if) we can handle this in a LTS release (I would personally use the
> > latest Ubuntu for that purpose, not the LTS). We will face to people who
> > will want the latest rails version on LTS (even if it breaks old
> > applications). We already have a similar discussion with Samba on a
> > previous meeting, but we did not found a consensus.
> If people want the latest and greatest they could just use rubygems to
> install it, rails apps try to use the system wide installed version,
> unless there is a gem version installed, this problem kind of solves
> itself here. As far as support for LTS releases, we could just support
> the packaged version.

The policy is to support what has been tested and marked as stable when
Ubuntu was released. If people want to use newer version, there is the
backport project available.


ubuntu-server mailing list
More info: https://wiki.ubuntu.com/ServerTeam
Old 11-22-2007, 02:50 PM
"Mamading Ceesay"
Default RubyOnRails for Hardy (Was: Server Team 2007-11-20 meeting minutes)

On 22/11/2007, Mathias Gug <mathiaz@ubuntu.com> wrote:
> What is the other option you recommend for a RoR stack ?

Deployments by leading Rails specialists such as EngineYard are
currently using Nginx + Evented Mongrel and moving towards Nginx +
Swiftiplied Mongrel.

Slides for background on this at:

Check out http://brainspl.at/articles/tag/nginx and
http://brainspl.at/articles/tag/mongrel for more up to date info,
technical drilldown and actual configuration files.

There is a google group worth connecting with on this topic:

Mamading Ceesay

If you only watch one movie this year, watch Invisible Children.

"We are here to help each other through this thing, whatever it is."
--Kurt Vonnegut, 1922 - 2007

ubuntu-server mailing list
More info: https://wiki.ubuntu.com/ServerTeam

Thread Tools

All times are GMT. The time now is 06:37 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org