perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoffrey Young <ge...@modperlcookbook.org>
Subject Re: CGI.pm dependency in Apache2::Status
Date Fri, 11 Mar 2005 13:41:48 GMT

> 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: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Mime
View raw message