Adam Kennedy <[EMAIL PROTECTED]> writes:
>> Look, there are already a few packages on CPAN that apparently run
>> well on either architecture, and we won't be asking those people to
>> maintain (and interface with) multiple packages that are otherwise
>> functionally identical.
>
> But they don't HAVE to maintain multiple packages. If _their_ API stays
> unchanged and can work quite happily with either, there is no reason for them
> to change.
I don't see how this concept works for Apache::VMonitor. If we
name your last statement above as property "P", Apache::VMonitor has P.
However it lists Apache::Scoreboard as a prereq, which at the moment
has two "generations" on CPAN. Both generations have enough in
common for Apache::VMonitor to claim P, but only one of the
Apache::Scoreboard distros can be indexed by CPAN. Currently
that's the 2.x generation (I think), which means that Apache::VMonitor
has a broken set of prereqs for existing mp1 users.
Keeping in mind that this is perhaps little more than an academic
discussion now....
Can you explain how renaming the 2.x generation to Apache2::Scoreboard
will allow Apache::VMonitor to still claim "P"? I don't see how
that's possible without at least these mods to Apache::VMonitor:
1) writing a set of conditional prereqs into its Makefile.PL,
2) recoding the implementation to use Apache${X}::Scoreboard,
3) creating a transparent Apache2::VMonitor package and listing
that as an indexed module.
So it looks to me like the proposed Apache::Scoreboard ->
Apache2::Scoreboard restores Apache::VMonitor's mp1 prereqs
to working condition. And it would require a small bit of
effort to make the module available to mp2 users, who would
demand the vacuous Apache2::VMonitor. But folks targeting
both platforms would be back to writing Apache${X}::VMonitor
everywhere. Yuck.
--
Joe Schaefer
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
