Audit a Perl 5.36.1 Upgrade with perl5361delta

Deciding whether a Perl 5.36.1 upgrade is safe takes more than reading a changelog, and perl5361delta alone will not tell you. This guide builds a small, repeatable review instead: find the interpreter you are actually running, read the release-specific changes, check the bundled module version, and exercise the two code paths the release actually fixed. It runs on a server or workstation without installing Perl or touching system configuration, and takes about fifteen minutes.

You need a shell, Perl, and the perl-doc package if you want to read the manual directly. The examples are read-only apart from temporary files you choose to create, and none of them need sudo.

1. Confirm which Perl you are reviewing

Start with the interpreter and documentation actually available on this machine. Do not assume the perl your shell finds is the one a service, virtual environment or deployment script uses.

$ command -v perl
/usr/bin/perl
$ perl -V:version -V:archname
version='5.38.2';
archname='x86_64-linux-gnu-thread-multi';
$ 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 paths and package revision can differ. The important distinction: perl5361delta documents the change from Perl 5.36.0 to 5.36.1, while the interpreter above is Perl 5.38.2. Treat the manual as a release note, not proof that this host runs 5.36.1.

2. Read the release note locally

Ask perldoc for the document directly, an ordinary read-only command:

$ perldoc -T perl5361delta | sed -n '1,100p'

• No intentionally incompatible changes relative to 5.36.0.
• Module::CoreList updated from 5.20220520 to 5.20230423.
• A build-system change for malloc() and free() probing on Solaris with a C++ compiler.
• Three interpreter fixes, covered in steps 4 to 6 below.

If your starting point is earlier than 5.36.0, read perl5360delta first. And do not turn "no intentionally incompatible changes" into a promise that every application upgrade is risk-free: it describes the release's compatibility policy, not your dependencies, your compiler or the bugs your code accidentally relies on.

3. Check the bundled module version

Query the module belonging to the interpreter you actually selected, not a separate Perl installation sitting elsewhere on the box:

$ perl -MModule::CoreList -E 'say $Module::CoreList::VERSION'
5.20231129

A later version than the release note's is normal on a later Perl. This command only checks the local installation; it does not prove an older 5.36.1 package is present. If Perl says the module cannot be found, inspect perl -V and the package contents before adding paths or installing anything.

Use the module's data for release questions, not for deciding whether your own application is compatible. That still needs your application's test suite and its dependency lock or package metadata.

4. Exercise the documented evaluator fix

One 5.36.1 fix covered an eval used as the final statement in a regular-expression code block, where older interpreters could panic. Keep the smoke test small and its result explicit:

$ perl -we '"abc" =~ /(?{ eval { 1 }; })/; print "regex-eval-ok\n"'
regex-eval-ok

This only confirms the selected interpreter completed the construct. It is not a full regression test for the historical crash, and success on Perl 5.38.2 says nothing about how Perl 5.36.0 behaved. For an actual upgrade decision, run your application's own tests under both the old and new interpreters wherever that comparison is possible.

5. Exercise a lexical-scope check

The release note also describes an assertion failure involving eval EXPR and a lexical sub defined in a grandparent scope. Keep the check isolated and its result visible:

$ perl -we 'my $make = sub { my $value = "scope-ok"; sub { eval q{$value} } }; my $read = $make->(); die "unexpected result\n" unless $read->() eq "scope-ok"; print "lexical-eval-ok\n"'
lexical-eval-ok

If you turn this into a real test file, add use strict; and use warnings;, then assert the exact result your application actually requires. Keep it under version control so it stays a regression check, not a one-off command you never run again.

6. Keep output-handle tests separate

The third fix concerns writes to magic variables tied to the selected output handle, including $^, $~, $=, $- and $%, after that handle's IO object has been cleared. This is specialised formatter behaviour, so do not manufacture a production configuration change just to probe it.

7. Separate source fixes from build fixes

The Solaris note is about Configure, not a runtime switch: Perl stopped probing the return types of malloc() and free() because C already defines those types, though command-line arguments and hints can still override them when needed. If you build Perl on Solaris with a C++ compiler, keep the complete configure command, compiler version and log with the build record.

Do not copy configure overrides from an unrelated host. Reproduce the build failure first, then check the generated configuration and the compiler diagnostics. On a normal packaged Linux installation, this is background information, not a reason to change local settings.

8. Record the upgrade decision

Write down the interpreter path, version, architecture, package revision, module version and test results, including whether you tested under the application's real service account. If a test fails, preserve the error and stop before touching dependencies or adding compatibility flags. A failed smoke test is evidence to investigate, not a prompt to silence the warning.