On 7/18/2004 5:14 AM Smylers wrote:
> [...]
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 requires the other distro authors to modify their packages. If they don't, then the feature can't be used.
Take modules which interface with the serial port, for example. There's Win32::SerialPort (which hasn't been updated in years), and there's Device::SerialPort. One is for Windows, the other for Unix and imitates the Windows interface.
So a module which needs the serial port requires either Win32::SerialPort or Device::SerialPort.
My only way around it for some of the GPS::* modules I wrote was to say it 'recommends' both modules, which it really doesn't.
I could put a dynamic config in the Build.PL but that causes the Makefile.PL and META.yml to reflect the platform that the dist was built on. Not good.
It makes more sense to say 'requires_one_of'. Changes would only have to be made to the modules that handle builds and installation. Nobody else needs change their distros unless they want to use that feature.
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.
What one person needs to keep an exhaustive list? An exhaustive list of what?
Expecting hundreds of CPAN authors to change their distros, and to have groups of them agree on "abstract" interfaces to provide, is not practical.
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 choice as to whether to support another feature is up to a module author. If you don't want to put the extra work in, don't. Other authors would.
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. ...
