I am getting the feeling you haven't understood what I am talking about, and you are also proposing something as "virtual packages" that is completely different from how "virtual packages" actually work, at least in Debian.
The key points are:
1. Virtual packages exist in the repository only.
2. Provision of a virtual package by any real one is decided by the real package's author, by claiming (via package metadata) to provide this package.
erm, I think the confusion is my fault. In my original message I wrote two paragraphs about virtual packages. In the first I was describing the way Debian works. In the second, and what we have mostly been refering to in this discussion, I was describing a way we could have something similar in concept to Debian's virtual packages. The difference being that the psueudo virtual package (there's something wierd about that term) is entirely contained within the META.yml file. In function, it's really more of a macro than a virtual package, but unfortunately, I clouded the matter by using the same term. If you look again at my example META.yml entry:
requires:
db_driver: [postgresql] || [mysql]
[postgresql]:
DBD::Pg: 0
DataTime::Format::Pg: 0
[mysql]:
DBD::mysql: 0
DataTime::Format::mysql: 0In this case I was calling "db_driver" a virtual package because it represents a requirement, but is not an actual module; It represents a requirement that may be satisfied by any of the two modules listed. It serves the same basic purpose as Debian's as in Debians system, but it is implemented differently in that it is defined on a per package basis.
