David Wheeler writes: > 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.
Another point to consider is how such lists of alternatives could be added to, and whom should be doing the adding. If you've written something that depends on the Pg_or_mysql virtual package then your application will only install with either of those DBD drivers, even if somebody else later comes up with a compatible driver that your code would actually work with. This isn't far-fetched -- DBD::PgPP exists, for example, and has the aim of being compatible with DBD::Pg. Rather than the dependent app (or module) having a list alternatives that are known to work, it could instead depend on some 'abstract' package. Other distros are then able to say that they 'provide' that abstract package. So if another module is writtent that has equivalent functionality and the same interface then it just needs to label itself as 'provide'-ing that 'abstract' package, and the dependent app will just work with it. That nicely puts control of whether a distro provides certain functionality in control of each distro's author; the knowledge is in the system as a whole, and no one person has to keep an exhaustive list up to date. Also, David has an app that depends on something Pg-or-mysql-like; suppose I do too, as do several other people. When another Pg-or-mysql-providing module appears it doesn't make sense for every single one of us app authors to have to note this, tweak our install settings, and upload a new version to Cpan; that's lots of duplicated and redundant effort. The obvious flaw in my proposal for this particular instance is that Pg and mysql don't provide identical interfaces, so I'm guessing that David hasn't written code that just happens to work with either of them but has conditions in it specifically to deal with their differences. To make a 'provides' feature work, those differences would have to be abstracted out elsewhere. For example, something like this could work: David determines exactly which features are needed from a DBMS by his app, and specifies the interface that his app will use to access them. DBD::mysql::Wheelerish is written; it depends on DBD::mysql and provides DBD::Wheelerish; the code puts the defined interface on the 'MySQL'-specific stuff. Similarly DBD::Pg::Wheelerish does the same thing for 'Postgres', depending on DBD::Pg and providing DBD::Wheelerish. David's app then depends on DBD::Wheelerish; it doesn't care about (or even know) which DBMS is being used, and will happily work with anything that has those features. In the future somebody writes DBD::Oracle::Wheelerish. David's app will now just work with Oracle without him having to do anything with it at all. Almost certainly "Wheelerish" isn't the best name here, but without knowing what the features in question are I couldn't think of anything more specific. Smylers
