Rubygems has a bug [1] where the install process can exit with a zero exit status even if the installation went wrong. The following patch adds a test that makes sure that the gem is installed. The bug is reproductible on 0.8.11-r5 and 0.9.0. I suspect other versions to be affected as well. I'm pretty new to Gentoo Bugs so I don't know what patch format you're using. The patch that will be attached to that bug was produced with no flags. Let me know if you need more informations. Cheers, zimbatm [1] : See the URL of that bug.
Created attachment 104591 [details, diff] this is the mentioned patch
(In reply to comment #0) > I'm pretty new to Gentoo Bugs so I don't know what patch format you're using. Unified diffs are strongly preferred :)
Created attachment 104592 [details, diff] united diff version too late :)
Um.. are you sure using ${P} in "specifications/${P}.gemspec" is right? This could be ${MY_P} in some cases (dev-ruby/mega-modules for example)
(In reply to comment #4) > Um.. are you sure using ${P} in "specifications/${P}.gemspec" is right? This > could be ${MY_P} in some cases (dev-ruby/mega-modules for example) No, you're right. Btw, dev-ruby/mega-modules is a good example of what should not happen. The gem has a "nano" dependency that the ebuild doesn't provide. So at the end you get a successful installation report from portage but no file was installed. Now that I think of it, checking for the emptiness of the specifications folder should be enough. What do you think ?
(In reply to comment #5) > Btw, dev-ruby/mega-modules is a good example of what should not happen. The gem > has a "nano" dependency that the ebuild doesn't provide. So at the end you get > a successful installation report from portage but no file was installed. Err.. I don't know :P I just grepped around to find if there is any package whos e package name is not identical to its gem name. I'll check mega-modules later > > Now that I think of it, checking for the emptiness of the specifications folder > should be enough. What do you think ? No. My specifications dir already has 24 gemspec files there. If the 25th fails to install it would report successful installation. I think your way is good enough if you check for MY_P as well (like the way GEM_SRC is set up). The ideal way is have rubygems return proper exit value (I'll investigate into this and maybe open a bug upstream)
(In reply to comment #6) > (In reply to comment #5) > > Now that I think of it, checking for the emptiness of the specifications folder > > should be enough. What do you think ? > > No. My specifications dir already has 24 gemspec files there. If the 25th fails > to install it would report successful installation. I think your way is good > enough if you check for MY_P as well (like the way GEM_SRC is set up). Yes, well it's checked in the sandbox so the previously installed gems don't matter. But I think the MY_P-P check is more precise. > The ideal way is have rubygems return proper exit value (I'll investigate into > this and maybe open a bug upstream) Done. See : http://rubyforge.org/tracker/index.php?func=detail&aid=7424&group_id=126&atid=575
http://rubyforge.org/tracker/?group_id=126&atid=575&func=detail&aid=7424 has been fixed and closed. The next rubygems release will behave correctly. Does this bug still matter ?
(In reply to comment #8) > http://rubyforge.org/tracker/?group_id=126&atid=575&func=detail&aid=7424 has > been fixed and closed. The next rubygems release will behave correctly. Yeah, maybe r1117 have fixed it > > Does this bug still matter ? As long as gems.eclass uses older rubygems, I think it still matter.
Created attachment 104733 [details, diff] United diff with the previous MY_P mentioned issue I've tested the following cases : * Installing an ebuild that uses the gems eclass * Installing an ebuild that uses the gems eclass with a broken gem dependency (using MY_P)
It's in. Thanks for your contribution.
