You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Joe Schaefer <jo...@sunstarsys.com> on 2005/03/09 02:44:32 UTC
CGI.pm dependency in Apache2::Status (was: Re: svn commit: r156472
...)
Geoffrey Young <ge...@modperlcookbook.org> writes:
> geoff@apache.org wrote:
[...]
>> note you will need to alter CGI.pm to require Apache2 modules
>> just to get the server to start
>
> ok, these were pretty massive commits but this is the important part -
> the test suite is up and running again, with (the expected) large
> number of failures.
At this point I hope we're not very far from achieving 100% passing
on the test suite, but my mp2 tuits for this week are pretty much
exhausted now.
> the note above is the only caveat - Apache2::Status requires either
> libapreq or CGI.pm, and CGI.pm won't work in it's current state since
> it uses Apache::-based modules.
I've looked at the source, and I'm puzzled why there's even
a dependency on CGI or apreq2 in there. Looking at the handler's
treatment of the query string, it looks like the raw query string
is (part of) a subroutine name, so it's not in the "name=value" format.
For GET, that means CGI and apreq are pretty useless. Is there some
clever use of POST data with Apache2::Status?
> so, you'll need to adjust CGI.pm just to get things running again.
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.
In the meantime, there is some namespace aliasing cruft that
I added to t/conf/modperl_extra.pl, mainly to work around the
older CGI.pm. Not sure what we should do with that idea. I'm
generally opposed to binding *Apache:: and *Apache2::, but
doing it for a few select packages might be justifiable
somehow.
--
Joe Schaefer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: CGI.pm dependency in Apache2::Status
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>>>the note above is the only caveat - Apache2::Status requires either
>>>libapreq or CGI.pm, and CGI.pm won't work in it's current state since
>>>it uses Apache::-based modules.
>>
>>
>>I've looked at the source, and I'm puzzled why there's even
>>a dependency on CGI or apreq2 in there. Looking at the handler's
>>treatment of the query string, it looks like the raw query string
>>is (part of) a subroutine name, so it's not in the "name=value" format.
>>For GET, that means CGI and apreq are pretty useless. Is there some
>>clever use of POST data with Apache2::Status?
>
>
> stas, do you know the history here?
Nope. I just ported it to run to mp2. I didn't add that dependency.
From a quick look it seems that $q is passed to all subs, but it's not
used at all. I could be wrong though.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: CGI.pm dependency in Apache2::Status
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
>>the note above is the only caveat - Apache2::Status requires either
>>libapreq or CGI.pm, and CGI.pm won't work in it's current state since
>>it uses Apache::-based modules.
>
>
> I've looked at the source, and I'm puzzled why there's even
> a dependency on CGI or apreq2 in there. Looking at the handler's
> treatment of the query string, it looks like the raw query string
> is (part of) a subroutine name, so it's not in the "name=value" format.
> For GET, that means CGI and apreq are pretty useless. Is there some
> clever use of POST data with Apache2::Status?
stas, do you know the history here?
>
>
>>so, you'll need to adjust CGI.pm just to get things running again.
>
>
> 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.
>
> In the meantime, there is some namespace aliasing cruft that
> I added to t/conf/modperl_extra.pl, mainly to work around the
> older CGI.pm. Not sure what we should do with that idea. I'm
> generally opposed to binding *Apache:: and *Apache2::, but
> doing it for a few select packages might be justifiable
> somehow.
yeah, let's think on that. I have some time to work on this today, so I'll
get on it.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: CGI.pm dependency in Apache2::Status
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Tue, 15 Mar 2005, Geoffrey Young wrote:
[ ... ]
> >
> > +1 for putting a plain-old "2" in any $ENV{MOD_PERL_FOO} you like best.
>
> ok, that's fine with me. others should feel free to weigh
> in as well, though :)
Using just "2" is fine with me as well - it serves the
purpose for now, and as you mentioned, mod_perl's $VERSION
can be used if a greater degree of accuracy is ever
required.
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: CGI.pm dependency in Apache2::Status
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> The problem before us now is basically this: how do we extract the old
> "generations" concept *out of* the installation layout (ie MP_INST_APACHE2)
> and incorporate it directly *into* the runtime? Remember, we didn't have a
> minor-number gradation for the layout (after all, it wasn't Apache2_0.pm),
> so we shouldn't *need* one for what we're trying to do with the runtime.
> If you see a future advantage to exposing a minor API number, please
> expain that.
yes, it was thoughts about the future, but nothing I can concretely
pinpoint. I guess what I saw the possibility of was people using this new
API variable as a way to distinguish, say, which form of Apache2::Foo->bar()
to call. but they can just as easily do that with $mod_perl::VERSION I
suppose.
>
> Remember what we decided in the pmc:
>
> 1) mp2 will install in parallel with mp1,
> 2) future mp2 releases will supercede prior mp2 releases,
> 3) whoever is doing mp3 will get to decide what to do
> about the existing mp1 & mp2 codebases, when that time comes.
yeah, I wasn't trying to achieve a 2.0 versus 2.1 versus 3.0 level of
granularity. it was more users being able to say "ah, 2.13 was the minor
bump that changes things important to our app" and having $bump be a simple
integer comparison, versus saying the same thing about 2.002_14-dev.
but don't worry, I'm not all that concerned about all of this - you asked me
to explain so I did :)
>
>
>>so, I dunno. perhaps we don't need the full major/minor bits a la
>>httpd, but something between "2" and "20050315.12"
>
>
> +1 for putting a plain-old "2" in any $ENV{MOD_PERL_FOO} you like best.
ok, that's fine with me. others should feel free to weigh in as well, though :)
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: CGI.pm dependency in Apache2::Status
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Geoffrey Young <ge...@modperlcookbook.org> writes:
[...]
> but the idea I had was to present something that was clear and easy to
> parse that modules could rely on going forward, the thought being that
> "mod_perl/1.999_21-dev" wasn't nearly as clear or simple as "2.1"
> where 2 was some major revision (like mp2) and 1 was some minor API
> ideal.
Agreed, but "2" is tough to beat when the criterion is "easy to parse".
Keep in mind I'm just questioning the rationale for having a minor
number, because it looks confusing to me. Let me try to explain why...
The problem before us now is basically this: how do we extract the old
"generations" concept *out of* the installation layout (ie MP_INST_APACHE2)
and incorporate it directly *into* the runtime? Remember, we didn't have a
minor-number gradation for the layout (after all, it wasn't Apache2_0.pm),
so we shouldn't *need* one for what we're trying to do with the runtime.
If you see a future advantage to exposing a minor API number, please
expain that.
Remember what we decided in the pmc:
1) mp2 will install in parallel with mp1,
2) future mp2 releases will supercede prior mp2 releases,
3) whoever is doing mp3 will get to decide what to do
about the existing mp1 & mp2 codebases, when that time comes.
> so, I dunno. perhaps we don't need the full major/minor bits a la
> httpd, but something between "2" and "20050315.12"
+1 for putting a plain-old "2" in any $ENV{MOD_PERL_FOO} you like best.
--
Joe Schaefer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: CGI.pm dependency in Apache2::Status
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> [...nice work!...]
:)
> I'm curious why we want to create a "module-magic-number" like the
> $API_VERSION you've got here. Does it convey any useful information
> beyond what's already in $VERSION?
not really. I guess I thought it was somewhat easier to parse than the
current $VERSION is all.
>
> Hmm, perhaps you are trying to kill two birds with one stone here
> (mp1-back-compat and future ABI changes in the httpd 2.x line)?
> If so, I think httpd handles ABI changes all by itself, by refusing
> to even load ABI-incompatible modules.
well, I was thinking abi on from an perl or xs pov, which httpd wouldn't
cover. but I guess you're right.
>
> As far as CGI.pm is concerned, it doesn't need this level of detail;
> it just needs to know which mod_perl module to require.
yes.
> An
> "generation" integer would probably suffice for that (or even my old
> "exists $ENV{MOD_PERL2}" idea). IOW, here's my +1 for making the
> patch set $ENV{MOD_PERL_API_VERSION} = 2 (or MOD_PERL_GENERATION
> if you prefer).
well, if we go that route I don't think we need anything beyond guaranteeing
that $ENV{MOD_PERL} is not only true, but will contain the version from here
on out. but the idea I had was to present something that was clear and easy
to parse that modules could rely on going forward, the thought being that
"mod_perl/1.999_21-dev" wasn't nearly as clear or simple as "2.1" where 2
was some major revision (like mp2) and 1 was some minor API ideal.
so, I dunno. perhaps we don't need the full major/minor bits a la httpd,
but something between "2" and "20050315.12"
?
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: CGI.pm dependency in Apache2::Status
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Geoffrey Young <ge...@modperlcookbook.org> writes:
[...]
> ok, attached is a patch that creates $ENV{MOD_PERL_API_VERSION} based
> on some information in mod_perl2.pm.
>
> feedback welcome.
[...nice work!...]
> Index: lib/mod_perl2.pm
> ===================================================================
> --- lib/mod_perl2.pm (revision 157559)
> +++ lib/mod_perl2.pm (working copy)
> @@ -34,6 +34,16 @@
> # $VERSION : "1.099020"
> # int $VERSION : 1.09902
> # $VERSION_TRIPLET: 1.99.20
> +
> + # mod_perl equivalent of httpd module magic number
> + # basically
> + # - bump the major version for binary-incompatible
> + # - bump the minor version for API changes
> + # - if you bump the major version, reset the minor to 0
> + our $API_VERSION_MAJOR = 20050315;
> + our $API_VERSION_MINOR = 0;
> + our $API_VERSION = join '.', $API_VERSION_MAJOR,
> + $API_VERSION_MINOR/100;
> }
>
> $mod_perl::VERSION = $mod_perl2::VERSION;
>
> ---------------------------------------------------------------------
I'm curious why we want to create a "module-magic-number" like the
$API_VERSION you've got here. Does it convey any useful information
beyond what's already in $VERSION?
Hmm, perhaps you are trying to kill two birds with one stone here
(mp1-back-compat and future ABI changes in the httpd 2.x line)?
If so, I think httpd handles ABI changes all by itself, by refusing
to even load ABI-incompatible modules.
As far as CGI.pm is concerned, it doesn't need this level of detail;
it just needs to know which mod_perl module to require. An
"generation" integer would probably suffice for that (or even my old
"exists $ENV{MOD_PERL2}" idea). IOW, here's my +1 for making the
patch set $ENV{MOD_PERL_API_VERSION} = 2 (or MOD_PERL_GENERATION
if you prefer).
--
Joe Schaefer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: CGI.pm dependency in Apache2::Status
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
Geoffrey Young wrote:
>>+1 for either documenting the format
>>of $ENV{MOD_PERL} so folks can parse it, or (preferably)
>>creating a new env variable that contains either the
>>version number or the API generation.
>
>
> yeah, I'm in favor of a new variable too. I'll probably get around to
> implementing it on monday then I'll post it for review. thoughts in the
> meanwhile still appreciated :)
ok, attached is a patch that creates $ENV{MOD_PERL_API_VERSION} based on
some information in mod_perl2.pm.
feedback welcome.
--Geoff
Re: CGI.pm dependency in Apache2::Status
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
> /me notes stas' silence on all things unstable ;)
You know well that I'm against this Apache2 rename frenzy. What do you
expect me to say?
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: CGI.pm dependency in Apache2::Status
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> +1 for either documenting the format
> of $ENV{MOD_PERL} so folks can parse it, or (preferably)
> creating a new env variable that contains either the
> version number or the API generation.
yeah, I'm in favor of a new variable too. I'll probably get around to
implementing it on monday then I'll post it for review. thoughts in the
meanwhile still appreciated :)
/me notes stas' silence on all things unstable ;)
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: CGI.pm dependency in Apache2::Status
Posted by Joe Schaefer <jo...@sunstarsys.com>.
"Christopher H. Laco" <cl...@chrislaco.com> writes:
> Geoffrey Young wrote:
>
>>>While I'm sure my opinion is extremely low on the totem, I'd much prefer:
>>>
>>> $ENV{MOD_PERL} and $ENV{MOD_PERL_VERSION}
>> yeah, I was going to suggest something along these lines. perhaps
>> MOD_PERL_API_VERSION which we can use to affect abi compat or something. I
>> just didn't know if the overhead of another mandatory insertion into %ENV
>> was worth it, but we may be leaving ourselves with no recourse here.
>
> That's what led me to the other option of actually setting $ENV{MOD_PERL} to
> the verion instead of just true; the two birds with one stone thing.
But we can't wind the clock back for mp1, so whatever its
been producing in $ENV{MOD_PERL} isn't something we
should try to change now. +1 for either documenting the format
of $ENV{MOD_PERL} so folks can parse it, or (preferably)
creating a new env variable that contains either the
version number or the API generation.
--
Joe Schaefer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: CGI.pm dependency in Apache2::Status
Posted by "Christopher H. Laco" <cl...@chrislaco.com>.
Geoffrey Young wrote:
>>While I'm sure my opinion is extremely low on the totem, I'd much prefer:
>>
>> $ENV{MOD_PERL} and $ENV{MOD_PERL_VERSION}
>
>
> yeah, I was going to suggest something along these lines. perhaps
> MOD_PERL_API_VERSION which we can use to affect abi compat or something. I
> just didn't know if the overhead of another mandatory insertion into %ENV
> was worth it, but we may be leaving ourselves with no recourse here.
That's what led me to the other option of actually setting
$ENV{MOD_PERL} to the verion instead of just true; the two birds with
one stone thing.
-=Chris
Re: CGI.pm dependency in Apache2::Status
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> While I'm sure my opinion is extremely low on the totem, I'd much prefer:
>
> $ENV{MOD_PERL} and $ENV{MOD_PERL_VERSION}
yeah, I was going to suggest something along these lines. perhaps
MOD_PERL_API_VERSION which we can use to affect abi compat or something. I
just didn't know if the overhead of another mandatory insertion into %ENV
was worth it, but we may be leaving ourselves with no recourse here.
>
> But that in and of itself means just checking $ENV{MOD_PERL} in MP1
> modules isn't enough, so maybe it's not good to want. :-)
>
> I'm going to show my sillyness. What does $ENV{MOD_PERL} actually
> contain? I always do if against it, but I've never looked at it's
> contents. Could $ENV{MOD_PERL} be made to hold the MP version, or would
> that break to many things?
I think it does, though the understanding in the docs and throughout time is
merely that it is "true" when running under mod_perl, not that it contains
anything reliable.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: CGI.pm dependency in Apache2::Status
Posted by "Christopher H. Laco" <cl...@chrislaco.com>.
Joe Schaefer wrote:
> Hmm, maybe we could have mp2 additionally expose $ENV{MOD_PERL2}?
> Then the logic becomes
>
> if (exists $ENV{MOD_PERL2}) {
> # running mp2
>
> }
> elsif exists ($ENV{MOD_PERL}) {
> # not mp2; must be mp1 then
>
> }
> else {
> # normal mode
>
> }
>
> or whatever. The point I'm trying to make is that the runtime
> is something we control, so marking the running mod_perl API
> via some runtime variable should be a workable approach.
>
While I'm sure my opinion is extremely low on the totem, I'd much prefer:
$ENV{MOD_PERL} and $ENV{MOD_PERL_VERSION}
But that in and of itself means just checking $ENV{MOD_PERL} in MP1
modules isn't enough, so maybe it's not good to want. :-)
I'm going to show my sillyness. What does $ENV{MOD_PERL} actually
contain? I always do if against it, but I've never looked at it's
contents. Could $ENV{MOD_PERL} be made to hold the MP version, or would
that break to many things?
What happens when MOD_PERL3 comes out? ;-)
-=Chris
Re: CGI.pm dependency in Apache2::Status
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Geoffrey Young <ge...@modperlcookbook.org> writes:
[...]
> that would mean re-parsing "mod_perl/1.29_01-dev" and
> "mod_perl/1.999.22-dev" and the like within CGI.pm, right? I guess
> so, but it feels like a lot of extra code in CGI.pm. but I guess we
> don't really have much choice.
Hmm, maybe we could have mp2 additionally expose $ENV{MOD_PERL2}?
Then the logic becomes
if (exists $ENV{MOD_PERL2}) {
# running mp2
}
elsif exists ($ENV{MOD_PERL}) {
# not mp2; must be mp1 then
}
else {
# normal mode
}
or whatever. The point I'm trying to make is that the runtime
is something we control, so marking the running mod_perl API
via some runtime variable should be a workable approach.
--
Joe Schaefer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: CGI.pm dependency in Apache2::Status
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
Joe Schaefer wrote:
> Geoffrey Young <ge...@modperlcookbook.org> writes:
>
>
> [...]
>
>
>>now, CGI.pm can try to decide whether it is running under mp1 or mp2,
>>but unless I'm missing something it's not all that easy.
>
>
> How about having it dispatch on the *value* of $ENV{MOD_PERL} (not
> just its mere existence), since the modperl runtime can control
> that?
that would mean re-parsing "mod_perl/1.29_01-dev" and
"mod_perl/1.999.22-dev" and the like within CGI.pm, right? I guess so, but
it feels like a lot of extra code in CGI.pm. but I guess we don't really
have much choice.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: CGI.pm dependency in Apache2::Status
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Geoffrey Young <ge...@modperlcookbook.org> writes:
[...]
> now, CGI.pm can try to decide whether it is running under mp1 or mp2,
> but unless I'm missing something it's not all that easy.
How about having it dispatch on the *value* of $ENV{MOD_PERL} (not
just its mere existence), since the modperl runtime can control
that?
> or CGI.pm can decide to eval the mp1 or mp2 API first, but I think
> that's the heart of the problem - nobody should have to make a choice
> like that at runtime.
Agreed; it needs to just work. Even with both mp1 and mp2 installed
in the same tree and running simultaneously.
--
Joe Schaefer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: CGI.pm dependency in Apache2::Status
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
Joe Schaefer wrote:
> Geoffrey Young <ge...@modperlcookbook.org> writes:
>
> [...]
>
>
>>so, I'm increasingly of the opinion that we should refuse to install
>>mod_perl 2.0 over any other existing mod_perl installation.
>
>
> +1 for refusing to install if a prior mp2 install exists,
done
> but
> I don't (yet) see the problem when just a prior mp1 is there.
I _think_ the issue is this...
before we called 'require mod_perl' and assumed that either
1) there was only one mod_perl in site_lib, so we could trust it, or
2) the user declared 'PerlModule Apache2' which would explicity give mp2
priority, and hence definitively tell CGI.pm which mod_perl environment it
is running under.
now, we have the possibility of both mod_perl.pm and mod_perl2.pm in the
same site_lib, which means that both can potentially be require'd
successfully. and if that happens CGI.pm needs to choose which one to belive.
now, CGI.pm can try to decide whether it is running under mp1 or mp2, but
unless I'm missing something it's not all that easy. or CGI.pm can decide to
eval the mp1 or mp2 API first, but I think that's the heart of the problem -
nobody should have to make a choice like that at runtime.
anyway, I'm just thinking out loud here, so if anyone has a solution I'm all
ears.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: CGI.pm dependency in Apache2::Status
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Geoffrey Young <ge...@modperlcookbook.org> writes:
[...]
> so, I'm increasingly of the opinion that we should refuse to install
> mod_perl 2.0 over any other existing mod_perl installation.
+1 for refusing to install if a prior mp2 install exists, but
I don't (yet) see the problem when just a prior mp1 is there.
> 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.
Amen to that.
--
Joe Schaefer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: CGI.pm dependency in Apache2::Status
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> 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