This is not at all comparable to the situation on CPAN. You can't just s/XML::Parser/XML::LibXML/g f.ex and expect it to work. Modules must be written to the interface of the module they use, and if they can pick from one of several alternatives, they have to be written towards all of these.
So I don't think there's a place for virtual distributions in the CPAN. The right approach is to explicitly state which alternative dependencies a module can use.
--As for the rest, it is mine.
But there are a *few*. DBI modules have been mentioned: it might be nice to have a virtual package that installs with the info needed to connect to your preferred database in a test configuration. Then the test phase can test against whatever database happens to be installed, automatically. The other one that comes to mind is the pgp/gpg modules: There are three with intentionally similar (and working on closing the gap) interfaces, depending on which program you want to use/have installed.
A virtual package in these cases would allow new modules to be added to the 'supports' list quite easily, and could allow for simpler test scripts. It is of limited utility, sure, but it is a non-zero utility. And the ability might encourage more people to create modules that could be virtualized this way.
Daniel T. Staal
--------------------------------------------------------------- This email copyright the author. Unless otherwise noted, you are expressly allowed to retransmit, quote, or otherwise use the contents for non-commercial purposes. This copyright will expire 5 years after the author's death, or in 30 years, whichever is longer, unless such a period is in excess of local copyright law. ---------------------------------------------------------------
