During this process also investigate which providers we have and which common use flags there are.
After some discussion the ruby team has decided that we will not introduce a new-style virtual for ruby. Most of the use cases for such a virtual are now handled by the new ruby-ng and ruby-fakegem eclasses, which depend on the proper ruby implementations based on the RUBY_TARGETS use flags.
Furthermore, different ruby implementations are not fully compatible when it comes to more advanced use such as building against its shared library, and thus specific dependencies are also needed in this case.
I've changed the subject to match this approach.
The following ebuilds still depend on virtual/ruby. Please check and update this dependency so that we can remove the virtual/ruby provider. If in doubt you may simply change the dependency to dev-lang/ruby, since this is the only version that currently provides virtual/ruby.
To be more future-proof, however, we encourage you to use the ruby-ng and ruby-fakegem eclasses to ensure that your packages is properly installed for all ruby targets that we provide. Feel free to ask the ruby herd for assistance with this.
If anyone feels like fixing swig for me, that would be great.
(In reply to comment #3)
> If anyone feels like fixing swig for me, that would be great.
The latest versions no longer depend on ruby at all, so if you stabilize one of those and remove the old versions you should be good to go.
(In reply to comment #2)
I've removed 9.1 from tree, but 9.11's ruby handling looks hackish.
If you can and want to, please go for it.
I've introduced pdflib-7.0.4_p4 to the tree which uses dev-lang/ruby as a dependency. As pdflib is essentially maintainer-needed, feel free to fix it properly.
(In reply to comment #2)
changed snd's virtual/ruby to dev-lang/ruby...
swig is already done. I cleaned up the old ebuilds some days ago.
I've checked this list again today and fixed the remaining packages. Removing cc's on the assumption that you won't be interested in the aftermath of actually removing the virtual.
I've just checked the tree and converted the last ruby packages referencing virtual/ruby. Next steps:
Remove the PROVIDE in ruby-enterprise and ruby 1.9.x. I'm not sure these should ever have qualified to be a virtual/ruby implementation given that neither is fully compatible with ruby 1.8. (perhaps ree18 comes close enough).
Remove the PROVIDE in dev-lang/ruby-1.8.x and the default in profile/**/virtuals.
I'm not sure if we can just do this or if there is some kind of transition period we should take into account?
I have removed the PROVIDE's for ruby 1.9 and ruby enterprise edition.
sci-libs/geos still depends on virtual/ruby.
(In reply to comment #13)
> sci-libs/geos still depends on virtual/ruby.
I already fixed that locally but forgot to commit. Thanks for the extra check.
Removed remaining PROVIDE's in ruby 1.8.