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

[Stephan Hermann]

Good Morning David, Scott,

On Thu, Aug 21, 2008 at 02:45:59PM -0400, Scott Kitterman wrote:
> On Thu, 21 Aug 2008 12:42:58 -0500 David Portwood <dzp at bellsouth.net> wrote:
> [...]
> >> 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?
> 
> I think that if gem was installing dependencies in a location that would 
> not interfere (e.g. be used instead of) installed system libraries, but 
> that the installed Gem could use the I could say yes to this.

Which is the case, when gem would use overlay dirs and those would LD_PRELOADED/LD_LIBRARY_PATHed properly
but this is something the ruby devs should take care of. In the meantime, the whole GEM stuff
is broken by design, and I don't understand people who are fighting with this. 

As said before, I think the best way to handle this:
Never ever use any other package management system, but from the used
distro. 

Regards,

-- 
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