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. * David Wheeler <[EMAIL PROTECTED]> [2004-07-17 23:39]: > On Jul 17, 2004, at 1:03 PM, A. Pagaltzis wrote: > > > Because it would be very silly to have a virtual package for > > XML::Parser and XML::LibXML -- they can't be used as drop-in > > replacements for one another. It *would* be useful to be able > > to say "I have written this module to work with XML::Parser > > v.$foo or XML::LibXML v.$bar". > > Right, in which case you would require the virtual package. > Otherwise...you wouldn't. But because of 2. above, you have no control over what is in the Any::XML::Parser virtual package. If you depend on it and someone writes the XML::Frobnitzer XML parser with a completely different interface and then adds XML::Frobnitzer to the Any::XML::Parser virtual package, it now suddenly satisfies your dependency, even though your module is not written to cope with XML::Frobnitzer. > > You can depend on DBI::Config v.$foo to indicate "I need a DBD > > which understands version $foo of the DBD interface" in that > > case. > > And how does the installer know that? Errm..? You list an appropriate version of DBI::Config as a regular Makefile.PL prerequisite, where the version of DBI::Config indicates the DBD interface version you want. The entire DBI::Config thing would, of course, be a DBI-specific convention. I already said all that in my initial mail on this thread. * David Wheeler <[EMAIL PROTECTED]> [2004-07-17 23:39]: > On Jul 17, 2004, at 1:09 PM, A. Pagaltzis wrote: > > > In fact you are arguing against virtual packages if the script > > only works with DBD::Pg or ::mysql, but not other DBDs -- > > because you'll need to depend on "::Pg or ::mysql" explicitly > > even if there was a virtual package for "any DBD". > > Then I would require the "Pg_or_mysql" virtual package. So instead of being able to "DBD::Pg or DBD::mysql" you have to pollute the repository with a virtual package first? > > Obviously being able to list alternative dependencies is of > > more utility than the existence of virtual packages. Not only > > that, but the latter would also require changes to CPAN (how > > likely is that to happen?), whereas a list of alternative > > dependencies only requires a spec for its format and an > > implementation in EU::MM and/or Module::Builder. > > How does it require changes to CPAN? It would have to be able to pull out information from distribution about which virtual packages they provide, at least, and offer it the way it maintains the modlist.txt. The rest could be done client-side, but that much would be necessary. Regards, -- Aristotle "If you can't laugh at yourself, you don't take life seriously enough."
