> This is something we will need to deal with. Once we
> can get a fixed CGI.pm on CPAN, I think we should list
> that as a prereq for mp2.
ok, I've been looking at how to fix this and I'm not sure I have the answer.
CGI.pm says this currently:
if (exists $ENV{MOD_PERL}) {
eval "require mod_perl";
if (defined $mod_perl::VERSION) {
if ($mod_perl::VERSION >= 1.99) {
$MOD_PERL = 2;
require Apache::Response;
require Apache::RequestRec;
require Apache::RequestUtil;
require APR::Pool;
} else {
$MOD_PERL = 1;
require Apache;
}
}
}
now, I was going to change this to
eval "require mod_perl";
eval "require mod_perl2";
if (defined $mod_perl::VERSION) {
if ($mod_perl::VERSION >= 1.99) {
require Apache::Response;
...
}
elsif ($mod_perl2::VERSION) {
require Apache2::Response;
...
} else {
...
}
but I'm not so sure I like it - it means that we can potentially be juggling
around 3 different mod_perl versions within the same site_lib, which is just
doomed.
but, that approach will work just fine if mod_perl refuses to install over
an existing mod_perl.pm, either mp1 or prior mp2 releases...
we are, of course, going to have a _huge_ migration effort on our hands once
the current path is released - people with Apache::Response and
Apache2::Response both in site_lib and their "porting" goes just fine until
they move to a new box and see they missed Apache2:: renames all over the
place. all in all, this strikes me as having a larger backlash in the
community than started all of this.
so, I'm increasingly of the opinion that we should refuse to install
mod_perl 2.0 over any other existing mod_perl installation. make them start
from a new perl tree, remove the old tree, or whatever. just minimize our
mailing list burden by doing this up front.
thoughts?
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
