He's not dead, he's resting

There’s something horribly wrong with Gentoo

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}
    Description               Virtual ebuild for rubygems
    Herds                     ruby
    Use flags                 
            (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.


6 responses to “There’s something horribly wrong with Gentoo

  1. zimous December 11, 2011 at 11:25 am

    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.

  2. Barry Schwartz December 16, 2011 at 5:51 am

    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.

  3. Steven Oliver December 21, 2011 at 3:16 am

    I hate to have to play the fool and ask, but what is so horrible about this ebuild for the uninitiated?

  4. AC December 11, 2012 at 1:10 am

    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.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s