Stas Bekman wrote: > Here is the problem. If a module fails to load once it must not be > blacklisted. The test demonstrates how a module may fail if loaded from > the wrong directory, but then is supposed to succeed if moved to a > different directory. this is somewhat addressed in the original thread: http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2003-09/msg01486.html http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2003-09/msg01518.html I think Rick makes a good point - in a persistent environment like mod_perl the file contents (or location) ought not to change during production, and for development we have the Apache::Reload/PerlFreshRestart options. and, as it turns out, it's PerlFreshRestart that is the culprit here - it explicitly sets each %INC entry to undef to allow for a reload, which now is a problem, since undef is now the trigger for a bad attempt. from rick's patch email: "The following patch arranges for failures to be cached in %INC as undef values (success is still cached as filename). I think this should be OK; I'm not aware of any other meaning for undef values in %INC (and neither is the test suite)." I think it would help mod_perl (and possibly others) is the trigger were something other than undef - a specific marker could blacklist the module, while undef could continue to work as before and allow for a reload. however, if perl isn't interested in changing current behavior, here is a patch that compensates for the changes within mod_perl. --Geoff