""" Provides-Release (multiple use) ::::::::::::::::::::::::::::::: [...] A release may also provide a "virtual" project name, which does not correspond to any separately-distributed project: such a name might be used to indicate an abstract capability which could be supplied by one of multiple projects. E.g., multiple projects might supply RDBMS bindings for use by a given ORM: each project might declare that it provides ``ORM-bindings``, allowing other projects to depend only on having at most one of them installed. """
1. I find this to be a strange example. If only one provided project (ORM-bindings) can be installed at any time, what if anyone wants to install more than one DB backends for ORM?
2. What is the expected behavior of 'pip install ORM-bindings'? To pick one of the many projects "providing" ORM-bindings?
3. Did anyone--Alexis and Tarek, in particular--think of real-world use cases for virtual projects (and even "provides" in general) other than the Zope transaction case? If yes, what are they?
4. Personally, I have needs for "virtual" packages from a binary (not source) distribution perspective. For example, "MySQL-python" can be a virtual package "provided by" the binary distributions: mysql5.1-python, mysql5.0-python; similarly, "psycopg2" can be provided by psycopg2-pg8.4 and psycopg2-pg9.0. Or, "modwsgi" can be provided by modwsgi-apache2.2, modwsgi-apache2.4. How would PEP 345's "Provides-Release" help, if at all, in describing this scenario?
 Or substitute `pip` with any package installer (easy_install, distutils2.install, pypm, enstaller).