On Thu, 21 Aug 2008 12:42:58 -0500 David Portwood <[EMAIL PROTECTED]> wrote: >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?
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. Scott K -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu