Geoffrey Young
2005-11-01 13:42:37 UTC
Hi,
is this really necessary in mod_perl2.pm?
I think the decision was made because a ton of legacy applications (likeis this really necessary in mod_perl2.pm?
CGI.pm) would be looking for $mod_perl::VERSION to decide which generation
they were after. whether this is a good idea or not... well, taking it away
now is probably a bad thing, so let's keep it, especially since that's not
the real problem...
see, $mod_perl::VERSION would report as a 2.0 version if someone
specifically loaded mod_perl2.pm. now, there's no reason for libapreq-1.33
to be doing that since it's specifically for mp1, which means...
$mod_perl::VERSION = $mod_perl2::VERSION;
$INC{"mod_perl.pm"} = File::Spec::Functions::devnull();
It makes libapreq fail to build when mp1 and mp2 are installed.
mod_perl 1.x ( < 1.99) is required at Makefile.PL line 34.
BEGIN failed--compilation aborted at Makefile.PL line 36.
the problem is actually in Apache-Test - Apache::Test tries to load up a$INC{"mod_perl.pm"} = File::Spec::Functions::devnull();
It makes libapreq fail to build when mp1 and mp2 are installed.
mod_perl 1.x ( < 1.99) is required at Makefile.PL line 34.
BEGIN failed--compilation aborted at Makefile.PL line 36.
bunch of mp2 classes when it itself is loaded, thus taking over the
mod_perl.pm slot in %INC. we've run into this problem before with
$mod_perl::VERSION incorrectly lingering and have tried to correct for it,
but apparently it didn't work.
so, please try the attached patch to Apache::Test. hopefully this fixes
things once and for all (without breaking more stuff :)
--Geoff