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
