Bugzilla Bug 93028

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 an attachment (id=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.