Bug#943380: perl 'control' autopkgtest fails in testing because libextutils-parsexs-perl not in testing

[Niko Tyni]

Control: tag -1 pending

On Wed, Oct 23, 2019 at 10:41:24PM -0700, Steve Langasek wrote:
> Source: perl
> Version: 5.30.0-7
> User: ubuntu-devel at lists.ubuntu.com
> Usertags: origin-ubuntu focal
> 
> Dear maintainers,
> 
> The perl autopkgtest passes in unstable, but consistently fails in testing
> and will continue to do so:
> 
> autopkgtest [06:39:56]: test control: prove debian/t/control.t
> autopkgtest [06:39:56]: test control: [-----------------------
> 
> #   Failed test 'Breaks for libextutils-parsexs-perl in perl-modules-5.30 matches Module::CoreList for ExtUtils::ParseXS'
> #   at debian/t/control.t line 219.
> #          got: '3.400000'
> #     expected: '3.40'
> # s/libextutils-parsexs-perl (<< 3.400000)/libextutils-parsexs-perl (<< 3.40)/
> # s/libextutils-parsexs-perl (= 3.400000)/libextutils-parsexs-perl (= 3.40)/
> # Looks like you failed 1 test of 452.
> debian/t/control.t .. 
> Dubious, test returned 1 (wstat 256, 0x100)
> Failed 1/452 subtests 
>         (less 113 skipped subtests: 338 okay)
> 
>   (https://ci.debian.net/packages/p/perl/testing/amd64/)
> 
> This test fails because debian/t/control.t relies on finding an existing
> package in the archive in order to figure out how far to zero-extend the
> version number that's provided by the upstream source data, before comparing
> with the contents of debian/control.
> 
> However, libextutils-parsexs-perl is not in testing /precisely because/ only
> an older version is available in the archive which is broken by current perl
> (bug #912682).  The test still passes in unstable, but at some point it may
> start to fail there also if the libextutils-parsexs-perl is removed from the
> archive.

Indeed. I noticed this right after the 5.30.0-8 upload but wanted that
to migrate first. It's fixed by

 https://salsa.debian.org/perl-team/interpreter/perl/commit/afc9c66ad31ca747d618d3109e94d54e55567bac

though clearly the solution is somewhat fragile and there's a danger
of accidentally reintroducing the issue in 5.32 again. I'll try to come
up with something better, probably listing the number of digits for the
special case packages.
 
> Regardless, this is an unreliable test because it depends on the state of
> packages in the archive which are not (test,build,runtime) dependencies of
> perl.  It looks like the release team may have overridden this failure once
> in order to let perl 5.30.0-7 migrate into testing, but this really ought to
> be resolved.

The fragility wrt. packages not available in the archive suite that we're
testing against could be fixed by listing the expected number of digits
for all the packages. I guess I'll look at that too.

However, the main point of the test is to have it fail if it spots new
packages in the archive that would need a corresponding Breaks/Replaces
entry. By your classification this makes it unreliable. I'm not sure if
this means I should disable it. That seems counterproductive to me.
-- 
Niko Tyni   ntyni at debian.org