Ruby on Rails support in Intrepid - call for reviewers and cheerleaders

[Stephan Hermann]

On Wed, Aug 20, 2008 at 02:07:46PM +0100, Neil Wilson wrote:
> Scott,
> 
> I'm trying to avoid the wheres and wherefores of what gem is about.
> Suffice to say that Rails depends upon effective gem support, such
> that the configuration of Rails can specify gem dependencies directly.
> 
> So if Ubuntu wants Rails, it has to have Gem that works. Therefore I
> saw my task as trying to get gem to work as a user would expect it to
> work without gem destroying the operating system, leaving cruft lying
> around the filesystem in the wrong place and try and prevent it
> running into itself too much
> 
> It's an exercise in containment.

What about teaching ROR to use an overlay, especially for the webapp you
code for?

I mean, the problem with gem is known...it's nasty...
afaik gem can do something like a destdir install somehow (when I'm not
mistaken and my mind is working in normal parameters, and my knowledge
from old ROR times is still valid).
If you have such a structure:

/var/www/ROR_App1/<... std ror dirs ...>
/var/www/ROR_App1/gems/<gem1> ...

this gems dir will be used as overlay, so somehow it needs to be
possible to LD_PRELOAD/LD_LIBRARY_PATH this directory (via config in
apache2/lighty/whereever)

> >>What are you referring to exactly ? Which use case do you have in mind ?
> >
> >It's my understanding that gems produces one complete package (gem) with
> >all Ruby libs needed to run the application and that there is no internal
> >notion of versioning.
> 
> Think of gem as a source package that generates binary packages on the
> fly. It has notions of build dependencies with other gems (including
> versioning) and run dependencies.
> 
> One thing it can do is manage several versions of the same gem on the
> machine at the same time.
> 
> For example the Rails gem depends upon the rake, activesupport,
> activerecord, actionpack, actionmailer and actionresource gems. You
> can install multiple different versions (usually one of each minor
> revision - 1.2.6, 2.0.2 and 2.1.0) and gem will ensure that the
> correct versions of the dependent gems are brought in at run time.

As long as gems are only delivering their own binaries...
But gems are much more, you can include complete (one or more) upstream
packages (I had this at one ocasion, there was this imagemagick gem and
this module was only working with a special imagemagick version, so it
shipped it together with the other cruft, but instead of installing it
somewhere where this imagemagick lib didn't hurt, it was just a smartass
and installed it in /usr/lib, overwriting the distro imagemagick).

This gem package didn't respect: DESTDIR, neither it respected the
./configure --prefix=<...> commands...so it destroyed other apps...but
this wasn't documented anywhere, btw.

so, having an overlay dir, where those gems can be installed without
disturbing the other software, fine...but not as it is now, and not
installing their stuff into /usr/local/lib or into /opt/foo....

Regards,
\sh

-- 
Stephan '\sh' Hermann		| OSS Developer & Systemadministrator
JID: sh at linux-server.org	| http://www.sourcecode.de/
GPG ID: 0xC098EFA8		| http://leonov.tv/
3D8B 5138 0852 DA7A B83F  DCCB C189 E733 C098 EFA8