followup on RT#36554

Hey,

It didn't seem like we came to much of a conclusion regarding the issue.  To throw a further kink, for the several boxes I am managing that displayed this error, I was able to fix it by turning off "DNS Hijacking" via changing the DNS servers on the routers for these machines.  So again, this really isn't a bug in URI or a bug in the test cases, but for the ISPs that are hijacking failed host name lookups (and they make it VERY hard to figure out how to turn this off) it shows up as a failed test.  So I'm thinking (based on some of the responses from the mailing list):

1) Test for DNS hijacking and vigorously warning the user about it.  Some suggestions could be added to the POD as well.  Skip the problematic tests in the case of DNS hijacking although warn about it and about the possibility of regressions in other modules (although personally I can't think of any).

2) As above but still run the test and tell the user she needs to either fix the DNS hijacking issue or force install.  That would push most the burden down to the end user and make sure she knew what she was doing by ignoring the issue.

3) Move all the tests requiring DNS so that you need some sort of ENV flag to enable them, like "URI_RUN_DNS_TESTS=1 make test".  That would let the developers test more agressively.

Personally I'd lean toward 1 or 2 since I don't think we should disable these kinds of tests entirely (and if we did option #3 most of those tests would never get run).  In general the test suite passes more than 95% of the time and fixing this issue alone would better that significantly.

I'd really like to work toward a solution since I am promoting Perl and Catalyst to a group of new developers who are learning from home and since they are on consumer oriented ISPs most of them have the DNS hijack issue.  Asking them to fiddle with their routers is not going to make things easier or make learning Perl more fun :)

Thanks!

John Napiorkowski