Re: Encode dependency

On Wed, Feb 11, 2009 at 23:10, Zefram <[email protected]> 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