Bug#925179: perl: autopkgtest failures on arm64, ppc64el and s390x: NDBM backwards binary compatibility

[Niko Tyni]

Package: perl
Version: 5.28.1-5
Severity: important

As seen at https://autopkgtest.ubuntu.com/packages/perl the NDBM
autopkgtest checks are failing on several 64-bit architectures.

These checks bundle binary NDBM databases generated on current sid/buster
and stretch versions of perl, and the purpose is to check that those
databases remain readable with the current version of perl.

We used to test this with just amd64 databases, but it turned out that
they are architecture specific, so we now ship separate test data files
for the different architectures.

All the test failures are issues with reading the stretch NDBM.

  autopkgtest [05:12:53]: test ndbm: [-----------------------
  testing NDBM reading...
  buster-ndbm OK
  opening NDBM file failed: No such file or directory at -e line 1.
  autopkgtest [05:12:54]: test ndbm: -----------------------]
  ndbm                 FAIL non-zero exit status 1

The "No such file or directory" is a misleading diagnostic here;
the files get opened correctly. The issue seems to be an actual
incompatibility with the stretch databases.

I can reproduce these on Debian porter machines. Clearly I should
have tested this better before including the data. Apologies for
any inconvenience caused.

The Perl NDBM support in Debian are built on the GDBM "old style dbm"
support (in the libgdbm-compat-dev package). The resulting database are
made of two identical files (*.dir and *.pag). I've checked that the
"gdbm_dump" utility from the gdbmtool package sid/buster can still read
the stretch database files. So this seems to be specific to the way the
Perl NDBM support is implemented.

A recent (separate) LFS-related backwards binary compatibility issue
in gdbm, #923609, was resolved by shipping a separate gdbm_dump-nolfs
utility that can be used to dump Stretch databases so that they can be
upgraded manually. The same avenue seems adequate for this issue as well.

I'm not sure if it's worth investigating what exactly goes wrong with
the compatibility, particularly as the combination of a non-mainstream
architecture and an obsolete database format makes it quite improbable
that any actual users will ever hit this.

I'm therefore inclined to just remove the stretch databases from the
test data on these architectures and be done with it.

I'm undecided on whether to do this for Buster or not. Will probably
check with the release team what they think. In any case, I'll wait
for -5 to enter testing first.
-- 
Niko Tyni   ntyni at debian.org