On Wed, Feb 11, 2009 at 23:10, Zefram <zef...@fysh.org> wrote: > LWP has a problem with older versions of Encode. With Encode version > 1.75 (which is the version included in a base perl-5.8.0), this test > failure occurs: > > base/message..............NOK 99/118# Test 99 got: <UNDEF> (base/message.t at > line 386) > # Expected: "a\x{FFFD}" > # base/message.t line 386 is: skip($NO_ENCODE, sub { $m->decoded_content }, > "a\x{FFFD}"); > base/message..............FAILED test 99 > Failed 1/118 tests, 99.15% okay (less 11 skipped tests: 106 okay, > 89.83%) > > Empirically, Encode version 1.9801 (as found in a base perl-5.8.1) > does not produce this failure. I don't think there's any need to probe > the versions in between; LWP could sanely reject all Encode versions > below 1.9801. > > Unfortunately LWP can't just declare a dependency on Encode-1.9801, > because it doesn't actually require Encode at all. But where Encode > is available, the version dependency ought to be handled in some > manner. The two places that do "require Encode;" should probably add > "Encode->VERSION(1.9801);". I'm not sure what could be done about > triggering an upgrade of an old Encode. If upgrading isn't feasible, > the test suite could set $NO_ENCODE if Encode is of too low a version. > > What do you think of these options? I'm happy to produce a patch for > whatever approach is agreed on.
Do you know if decoding always fails with this version of if it's only when \x{FFFD is substituted? If it always fails then we should just put in the Encode->VERSION(1.9801) assertion. If the decoding sometimes work adding this might break stuff that used to work for the poor perl-5.8.0 users. Otherwise I'm fine with disabling the failure for the test, but I would leave in some noise to warn that things are not really all good and that users should really upgrade to a newer perl. --Gisle