Ciaran McCreesh’s Blag
Now with 17% more caffeine
There’s something horribly wrong with Gentoo
Posted by on December 10, 2011
After a couple of months of it being switched off, the PSU in my Gentoo box decided to let its magic smoke escape. I made the mistake of replacing it, and now I see this:
* virtual/rubygems
::gentoo 1 {:ruby18} 2 {:jruby} 3* {:ree18} (4)KR {:ruby19} (5)K {:rbx}
virtual/rubygems-3:ree18::gentoo
Description Virtual ebuild for rubygems
Homepage
Herds ruby
Use flags
ruby_targets
(ree18) Build with Ruby Enterprise Edition 1.8.x
That someone thought that that was in any way a good idea pretty much sums up everything that’s wrong with Gentoo. I’m seriously considering just abandoning Gentoo support now — there comes a point when the accumulated bad design decisions would cost more to fix than the total worth of the product, and this plus the Python eclass are suggesting to me that Gentoo has passed that point.
Totally agreed, I have hit this braindead ebuild weeks ago. But I was not brave enough to file a bug report, just masked the slots and pushed it out of my consciousness ;) I want to thank you for your work on paludis a lot, I would have hard time switching back to portage.
I saw this today on planet gentoo:
http://blog.flameeyes.eu/2011/12/10/a-worldly-opponent
The comments in the ebuilds imply that this was one developer’s idiosyncratic decision. Considering that a lot of stuff gets done this way, I’m more inclined to admire that the results work as well as they do, than I am to decry the situation. That said, this set of ebuilds was a bad idea that I hope gets reversed, though if I figure out why this ruby stuff is on my system in the first place I may just try to change that.
I hate to have to play the fool and ask, but what is so horrible about this ebuild for the uninitiated?
Look at the versions and the slots.
I only just hit the consequences of this bug now. Why was it decided to put each slot into a separate version only? And the newest official stable ruby isn’t even the highest version!
In case someone else hits this problem: As workaround, I myself decided to both mask “virtual/rubygems” and unmask “virtual/rubygems:ruby19″ to use ruby19, letting the order of precedence of the respective config files work. I’m guessing this might be the most unchanging solution *until* the ebuild itself might get fixed. At which time it probably will error out automatically – which I want to happen.