httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Wheeler <>
Subject Re: libapreq-1.2 release candidate
Date Thu, 01 May 2003 02:16:41 GMT
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. 

> 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.


David Wheeler                                     AIM: dwTheory                              ICQ: 15726394
                                                Yahoo!: dew7e
Kineticode. Setting knowledge in motion.[sm]

View raw message