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.
Or if they want to move to the new API they can do what a number of perl modules have done over the years when they moved API and put a placeholder in the old namespace (installed from the same package).
package Apache::MyModule;
(do the main work)
1;
package Apache2::MyModule;
use base 'Apache::MyModule';
1;
... or if they want they _can_ maintain two different packages, give the old one to someone and call it "legacy", and do the new one differently.
There are a number of known solutions for the issues brought up by moving to a new namespace. We've done this stuff before and it's a solved problem.
To pick a few examples, you can have two different versions of the module and load them in at compile-time. You can work out which to use by switching between the two at run-time on a per-method-call basis. (As happens in some filesystem code).
If you like I could modify a couple of existing third-party Apache modules to show a couple of ways that this could be done sanely.
While I understand you have tried to keep the APIs similar, the problem remains that it is simply unworkable to maintain and support multiple different APIs within a set of arbitrary version ranges within a single module name.
If you'll forgive me for putting a name on the concept, I'll refer to it as "API overloading", where API overloading is defined as "supporting multiple production/stable/current, but incompatible, APIs within a single namespace".
API overloading simply will not work, as I demonstrated earlier. While you can reach the point where you can load the code, that's all you can really do without gradually replacing every other system and every other tool throughout all of perl, until you reach the point where what you have is mod_mp2perl.
Having had another day to look into the code, I suspect it can also be shown that the feature/mechanism you are using to implement API overloading is mutually exclusive to all other modules using the mechanism.
Only one API in any program is ever able to use the trick the Apache2.pm uses, unless you were to wrap up the entire of @INC into an anonymous CODE reference which redirects into a package that implements your new module resolver. You would probably also have to write a new Apache2/lib.pm instead of lib.pm, and/or turn @INC a tied array that lets all other perl modules treat it normally.
As I said, there are workarounds that can make this happen, but the number required just keeps increasing and increasing until you have forked or replaced every major system in perl.
The maintenance load of patches your version of lib.pm whenever the core lib.pm changes, or doing this for mp2doc, mp2cpan, mp2man, mp2pod2man, etc etc etc would be unbelievable.
--------------------------------------
Now, if you assume that API overloading in general is simply inviable, you are left with the same situation as every other perl module.
You either move to a new name, or you document that you are immediately and irrevocably end-of-life'ing all previous versions of that module.
These are your only two viable options that I can see...
I simply cannot believe that you would want to immediately make 5/6ths of your entire user base redundant and make them upgrade immediately. I know that you have tried to provide an upgrade path, but unfortunately that is what will happen.
If I were to speculate, the only alternative I can see if that mod_perl 2.0 was to be locked out of the indexer as stas suggested earlier.
The problem will be that mod_perl 2.0 and any other Apache:: third party modules that move over to the new API, are _ALL_ going to have to be locked out, to prevent mod_perl 1 installations "upgrading" to a newer version that is fatally incompatible.
This is not going to be for a year, it's going to be indefinitely. Or more likely for 5-10 years, until the mod_perl 1 userbase has largely completed porting over. Or possibly until perl 6 is released.
---------------------------------------
But I'm starting to go on and on again. Stas has said he will be responding shortly, once he has dealt with some bugs. We can wait for him before continuing.
Adam
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
