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

[David Portwood]

On Wed, 2008-08-20 at 15:31 +0200, Stephan Hermann wrote:
> 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 is a good example of that, and it happens on more than just debian
systems.  I do however feel that Neils proposed change(s) to the gems
package has the best intrest in mind without major changes to gem and
apt.  This is a step forward, no?

David P. macd(on)freenode
> 
> 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
>