Thanks for your work Neil! The ruby community is very much a bleeding edge group of developers, and so waiting 6 months between releases is really not useful. When I do my rails development on hardy, I install ruby, mysql, and ruby gems from apt, and from there use straight gems.
-- Darren On Wed, Aug 20, 2008 at 7:31 AM, Stephan Hermann <[EMAIL PROTECTED]> 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 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: [EMAIL PROTECTED] | http://www.sourcecode.de/ > GPG ID: 0xC098EFA8 | http://leonov.tv/ > 3D8B 5138 0852 DA7A B83F DCCB C189 E733 C098 EFA8 > > -- > Ubuntu-devel-discuss mailing list > [EMAIL PROTECTED] > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss > -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
