Attached you can found the ebuild for the new version from rake 10.0.2 can somebody update the portage to it.
(In reply to comment #0) > Attached you can found the ebuild for the new version from rake 10.0.2 can > somebody update the portage to it. There's no attachment. Note that we track gems automatically, so if a package doesn't appear it's either due to issues (see http://wiki.gentoo.org/wiki/Project:Ruby/Pending_Bumps ) or due to lack of man-power. If you want to help with the latter, please also include a build log with USE=doc and FEATURES=test.
I've added 10.1.0 to he pentoo overlay (without keywords) if it helps anyone. I've only tested with ruby19.
Without knowing that Rick had already done it, I made an ebuild for rake-10.1.0 and put it on ruby's overlay with ~amd64 and support for ruby18,19,20 and jruby.
(In reply to Michel Boaventura from comment #3) > Without knowing that Rick had already done it, I made an ebuild for > rake-10.1.0 and put it on ruby's overlay with ~amd64 and support for > ruby18,19,20 and jruby. Rake 10 doesn't support ruby18, so that's pretty impressive...
Quoting from the rake 10 release notes: Rake 10 is actually feature identical to the latest version of Rake 9 (that would be the version spelled 0.9.3), *except* that Rake 10 drops all the sundry deprecated features that have accumulated over the years. If your Rakefile is up to date and current with all the new features of Rake 10, you are ready to go. If your Rakefile still uses a few deprecated feeatures, feel free to use Rake 9 (0.9.3) with the same feature set. Just be aware that future features will be in Rake 10 family line. This means that if we drop rake 10 in the tree we can be certain to break many packages. This will happen even if we slot rake 10, since /usr/bin/rake will still pull in rake 10 automatically. Any thoughts on how we should approach this?
(In reply to Hans de Graaff from comment #5) > This means that if we drop rake 10 in the tree we can be certain to break > many packages. This will happen even if we slot rake 10, since /usr/bin/rake > will still pull in rake 10 automatically. Any thoughts on how we should > approach this? Same as we have done for every disruptive change in gentoo since the dawn of time. Bring it into the tree as masked or without keywords. Once a little testing has been done consider it for ~arch. Once the majority of the tree supports it move it to stable. We do this with glibc, gcc, python, etc all the time, not sure why it would be any different here.
Maybe it is possible to do some path manipulation inside of the eclass? So we could slot the rake ebuild and add something like RUBY_RAKE="0.9" to the broken gem. This will add a harddep on <rake-1 (rake:0.9) and uses a path that gives rake 0.9 the priority? All others will go by default with rake:10 or whatever is the best option installed. If the gem needs rake-10 (which is imho unlikely), then you could also add RUBY_RAKE="10"
rake 10.2.2 is now in the tree.