Portage strips the version from virtuals (so says jstubbs) and the next version of repoman reports versioned virtuals as a warning. Attached is the list of ebuilds affected by this (in repoman report format).
Created attachment 59176 [details] big ol' list of versioned virtuals
umm, we depend on versioned virtuals to be able to do the right thing in many cases. They work presently, so I don't see how you note that portage strips the version from them.
I'm on qa@ already. :) Related to this is bug #46968. I'm aware of the reasons where versioned virtuals are required and have put together GLEP 37 to address these and other issues. This check in repoman is to help smooth the transition to that (or a similar) scheme.
(In reply to comment #2) > umm, we depend on versioned virtuals to be able to do the right thing in many > cases. They work presently, so I don't see how you note that portage strips the > version from them. If you mean that you use versions with virtuals in *DEPEND, that is no problem. This bug is about versions appearing in PROVIDE.
just to make sure: we should just change it to provide without the versions and everything will keep working correctly?
It will keep working exactly the same, yes.
java fixed
Nice work from the java team. php...can you start working through these please? python only has the one so someone fix that up.
Does anyone in the python herd know the reason for this in python-2.1.3-r1? PROVIDE="virtual/python-2.1" The only thing that comes to mind is all the "package-2.1"'s that were needed when zope only worked with python 2.1.
no, the way I understand it, portage isn't even looking at that version in the PROVIDE.
Ok, I've clean up all PROVIDE variables for the PHP packages now.
dev-php/php, dev-php/mod_php, and dev-php/php-cgi still seem to have it.
sorry, missed commited the php-sapi eclass. fixed now.
Python fixed too.
