Audit a Perl 5.32.1 Upgrade with perl5321delta

You will use perl5321delta to turn the Perl 5.32.0 to 5.32.1 release notes into a short upgrade checklist, then verify that the documentation and installed package match your assumptions. This is a read-only review: it does not install Perl, restart a service or change application files.

Allow about fifteen minutes. You need a shell, the perl-doc package and enough access to inspect the Perl installation. The examples below were checked against Ubuntu's perl-doc 5.38.2-3.2ubuntu0.6; the document itself describes Perl 5.32.1, not the version currently installed here.

1. Confirm what is installed

Start with the interpreter and package versions. These commands are ordinary, read-only checks and do not need elevated privileges:

$ perl -v
This is perl 5, version 38, subversion 2 (v5.38.2)

$ dpkg-query -W -f='${Package} ${Version}\n' perl perl-base perl-doc
perl 5.38.2-3.2ubuntu0.6
perl-base 5.38.2-3.2ubuntu0.6
perl-doc 5.38.2-3.2ubuntu0.6

Your package version can differ. Record it beside the application upgrade ticket, because a release note for Perl 5.32.1 is historical evidence rather than proof of the behaviour of a later interpreter.

Checkpoint: if perl-doc is missing, stop here and install it through your normal package-management process. Do not substitute an unrelated web page or assume that a different perl5321delta file has the same contents.

2. Read the release document locally

Use perldoc when you want formatted text in the terminal:

$ perldoc perl5321delta | sed -n '1,80p'
NAME
    perl5321delta - what is new for perl v5.32.1

DESCRIPTION
    This document describes differences between the 5.32.0 release and the
    5.32.1 release.

The installed file is also available through man. Check which file will be used before relying on it:

$ man -w perl5321delta
/usr/share/man/man1/perl5321delta.1.gz
$ perldoc -l perl5321delta
/usr/share/perl/5.38/pod/perl5321delta.pod

These two paths are different representations of the same local documentation. man -w shows the compressed manual page used by man; perldoc -l shows the Pod source used by perldoc. If they resolve to unexpected locations, investigate the package and MANPATH before using the text for an audit.

3. Extract the changes that affect runtime code

The page says that there are no changes intentionally incompatible with Perl 5.32.0. That is a release statement, not a compatibility test for your application. Read the updated module list and diagnostics, then compare it with the modules your service actually loads.

For this release, the documented module updates include Data::Dumper 2.174_01, DynaLoader 1.47_01, Module::CoreList 5.20210123, Opcode 1.48 and Safe 2.41_01. The page specifically records memory-leak fixes in Data::Dumper, and a warning about evaluating untrusted code with the Perl interpreter for both Opcode and Safe.

Check the versions visible to the interpreter rather than relying only on the distribution package name:

$ perl -MData::Dumper -MDynaLoader -MModule::CoreList -MOpcode -MSafe -e \
  'printf "Data::Dumper %s\nDynaLoader %s\nModule::CoreList %s\nOpcode %s\nSafe %s\n", $Data::Dumper::VERSION, $DynaLoader::VERSION, $Module::CoreList::VERSION, $Opcode::VERSION, $Safe::VERSION'
Data::Dumper 2.174_01
DynaLoader 1.47_01
Module::CoreList 5.20210123
Opcode 1.48
Safe 2.41_01

The output above is the documented 5.32.1 set and is useful as a comparison target. On Perl 5.38.2, some core module versions may have moved on. Do not treat a mismatch as a failure until you have established which Perl installation the application uses.

4. Check the application interpreter, not just your shell

Multiple Perl installations are a common upgrade trap. The shell's perl may not be the interpreter used by a systemd unit, cron job or wrapper script. Inspect the service definition and its shebang through your normal change-review process, then run a harmless version check as the same account and with the same explicit path.

$ command -v perl
/usr/bin/perl
$ /usr/bin/perl -e 'printf "%s\n", $^V'
v5.38.2

If a script begins with #!/usr/bin/env perl, its interpreter depends on PATH. If it names /opt/perl/bin/perl, checking /usr/bin/perl tells you nothing about that application. Do not edit the shebang or service unit as part of this documentation check. Such a change needs its own rollout and rollback plan.

Checkpoint: write down the exact interpreter path, version and package source that the service will use after the upgrade. A successful perldoc command only proves that documentation is available in your current environment.

5. Review the security and build notes

The release document adds the new perlgov and perlsecpolicy documentation. It also records a range operator documentation change, a fix for an incorrectly raised \K diagnostic in some nested lookarounds, and fixes for several correctness and build problems.

Pay particular attention if your application evaluates code or uses the restricted-operation modules. The new warning about untrusted code is a prompt to review the trust boundary, not a replacement for sandboxing. Do not make a production service evaluate user-supplied Perl merely because the upgraded interpreter emits a warning instead of an error.

The page also documents fixes for list assignments involving undef, recursive regular-expression matching, a debug-memory build deadlock involving PERL_MEM_LOG, chained comparisons under no warnings 'uninitialized', and exceptions from destructors during global destruction. Turn those entries into targeted regression tests if your code uses the affected constructs.

6. Finish without changing state

Capture the local evidence and run the application's existing test suite under the exact interpreter path identified in step 4. For a simple command-line check, confirm that the interpreter can load the modules:

$ /usr/bin/perl -MData::Dumper -MDynaLoader -MModule::CoreList -MOpcode -MSafe -e 'print "core modules loaded\n"'
core modules loaded

This command does not exercise your application's behaviour, and it does not prove that every dependency is compatible. It only verifies that the selected interpreter can load the documented core modules.

No undo is required because every example in this guide reads metadata or starts a short-lived Perl process. If your wider upgrade has already changed a service or interpreter symlink, use the rollback procedure approved for that deployment. Do not improvise a symlink replacement with sudo.