Audit a Perl Upgrade with perl5302delta

You will finish with a small, repeatable audit for Perl 5.30.2: read the release-specific changes, compare them with the Perl and core-module versions actually installed, and identify the fixes that deserve regression tests. The examples use the perl5302delta documentation installed with Perl 5.38.2 on this machine. The document describes Perl 5.30.2; it does not mean that the host is running that older release.

Allow about fifteen minutes. You need a shell, the perl-doc package, and permission to read the Perl installation. The checks below are unprivileged and read-only. Do not run an upgrade, rebuild Perl, change a module, or restart an application as part of this guide.

1. Confirm the Perl and documentation versions

Start with the interpreter that your shell will find. This avoids auditing one Perl while an application uses another path:

$ command -v perl
/usr/bin/perl
$ perl -V:version
version='5.38.2';
$ dpkg-query -W -f='${Package} ${Version}\n' perl perl-doc
perl 5.38.2-3.2ubuntu0.6
perl-doc 5.38.2-3.2ubuntu0.6

Your package revision may differ. The useful facts are the interpreter version and whether perl-doc is installed. If the version is not 5.30.2, treat perl5302delta as historical release information, not as a description of the current runtime.

Checkpoint: record the exact output of perl -V:version in the upgrade ticket or test notes. If an application uses a version manager, container or private Perl tree, repeat this step from that environment.

2. Read the release notes through perldoc

Use the installed documentation rather than copying a page from an unrelated Perl installation:

$ command -v perldoc
/usr/bin/perldoc
$ perldoc perl5302delta | sed -n '1,80p'
NAME
    perl5302delta - what is new for perl v5.30.2

DESCRIPTION
    This document describes differences between the 5.30.1 release and the
    5.30.2 release.

The first boundary is easy to miss: this document covers 5.30.1 to 5.30.2. If you are starting from 5.30.0, the notes tell you to read perl5301delta first. For a larger version jump, read each relevant delta document or the distribution's complete Changes file. Do not treat one maintenance-release page as a complete upgrade plan.

If perldoc cannot find the page, locate the installed source without changing anything:

$ perldoc -l perl5302delta
/usr/share/perl/5.38/pod/perl5302delta.pod

A missing result usually means the documentation package is absent from this Perl installation. It is not evidence that the runtime is 5.30.2 or that the release notes do not exist.

3. Record the changes that can affect your workload

The 5.30.2 notes contain no intentionally incompatible changes. They list two upgraded core modules, GCC 10 support for Configure, a Windows MYMALLOC fix, and several bug fixes. The practical audit is to match those entries to code paths you use, rather than trying to test every line of the release notes.

• Compress::Raw::Bzip2 moved from 2.084 to 2.089.
• Module::CoreList moved from 5.20191110 to 5.20200314.
• Debugging builds no longer mishandle %n in printf or sprintf.
• A regular-expression memory leak, a buffer read beyond its limit, and an assertion failure were fixed.
• Regex (?{...}) evaluation groups no longer unintentionally hit the EVAL without pos change exceeded limit in regex condition.

The Windows note and the GCC 10 Configure note matter when building Perl, not when merely running a packaged interpreter on Linux. Keep them in the upgrade record if you compile Perl or support Windows, but do not invent a Linux runtime test for them.

4. Compare the named modules with the installed runtime

Check the two modules directly. These commands load code but do not install or modify it:

$ perl -MCompress::Raw::Bzip2 -e 'print "Compress::Raw::Bzip2 $Compress::Raw::Bzip2::VERSION\n"'
Compress::Raw::Bzip2 2.204001
$ perl -MModule::CoreList -e 'print "Module::CoreList $Module::CoreList::VERSION\n"'
Module::CoreList 5.20231129

The versions above are newer than the 5.30.2 values because this host runs Perl 5.38.2. That is expected. The comparison answers a narrower question: whether the active interpreter has module versions at least as new as the release-note baseline. It does not prove that an application is compatible with every later change.

If a module fails to load, stop and capture the error before trying sudo. A missing shared library, a local library path, or a different Perl in the application's service unit may be the real cause. Check command -v perl and the application's documented runtime path first.

5. Turn the bug fixes into focused tests

Use the release notes to choose tests that resemble your workload. For code using formatted output, cover the %n path only if your application genuinely uses it. For regex-heavy code, run the existing test suite with representative patterns and include a memory-checking build where your project already supports one. Do not paste a release-note example into production merely to claim coverage.

Keep the test result separate from the version result. A passing test on Perl 5.38.2 shows that the current interpreter handled that case. It does not recreate the 5.30.2 environment, and it cannot establish that a 5.30.1 system contains the fix. If you need to reproduce the old defect, use an isolated, disposable test environment and never replace a system Perl to do it.

For the regex evaluation-group fix, treat the feature as security-sensitive application logic. Review where patterns come from, keep untrusted patterns out of evaluation-capable constructs, and test timeouts or resource limits at the application boundary. The release note records a fixed failure mode; it does not make dynamic regex evaluation safe for arbitrary input.

6. Report gaps without changing the host

If your audit finds a mismatch, write down the command, interpreter path, version, module version and failing test. Avoid "fixing" the record by installing a second module into a shared location. That can alter which code future processes load and makes the original problem harder to reproduce.

When you have reduced a suspected Perl defect to a small test case, the manpage points to the Perl issue tracker. Remove private data before sharing it. For a suspected security problem, use Perl's security contact guidance rather than posting exploit details publicly. The perlthanks command mentioned by the documentation sends email to the Perl 5 Porters list; it is not part of an upgrade audit, so do not run it accidentally while copying commands.