httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <>
Subject Re: libapreq-1.2 release candidate
Date Thu, 01 May 2003 02:20:25 GMT
David Wheeler wrote:
> On Wednesday, April 30, 2003, at 09:06  PM, Stas Bekman wrote:
>> For example Apache::Test's 'make install' could hunt down  
>> Apache/ in @INC and delete it and install its own version of  
>> Apache/ which will still work as before and will be exactly 
>> the  same as Apache/
>> The problem is how to prevent from mod_perl 1.x upgrades from  
>> overwriting this. This certainly could be avoided by fixing the next  
>> mod_perl 1.28 release, but what if someone upgrades from 1.26 to 1.27?
> If you release mod_perl 1.28 tomorrow, I don't think that'll often be a  
> problem. I wouldn't mind seeing a fix for the "modules executed twice"  
> bug first, though.
> Modules_Executed_Twice_P47060/

was it fixed in cvs already?

>> Another possible solution is this:
>> Move all code from Apache/, but its $VERSION to  
>> Apache/ The latter will declare 'package Apache::Test'. 
>> So  you need to require Apache/ everywhere, but the rest 
>> will  work as before. What this approach achieves is that you don't 
>> have the  collision, while you still keep on using Apache::Test in 
>> your code.  Admittedly it's a bit confusing that you require 
>> Apache::TestCode, but  use Apache::Test:: functions.
> This is less elegant, but would work. Module authors have to do more  
> work, though. If you combine this with the above solution, though, you  
> could also then have Apache/ C<use Apache::TestCode>. Not sure  
> that would gain you much, though.

I'd certainly prefer to have a way for perl to do a case-sensitive require.

Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker     mod_perl Guide --->

View raw message