Use perl5121delta to audit a Perl 5.12.1 upgrade

You will use perl5121delta to review the changes between Perl 5.12.0 and 5.12.1, then compare that historical target with the Perl and module versions actually installed on a Linux host. The result is an evidence-based upgrade note, not a claim that reading a manual page upgrades Perl. Allow about 15 minutes for a host with a normal package installation.

This guide is read-only. The commands inspect documentation and report versions. They do not install packages, change @INC, modify applications or restart services. Run them as your ordinary user. Use sudo only for a package-management or service action you have separately reviewed; none is needed here.

1. Confirm the command and the installed Perl

Start by identifying which documentation command will run and which Perl interpreter your shell selects:

$ command -v perl
/usr/bin/perl
$ perl -e 'printf "%vd\n", $^V'
5.38.2
$ perldoc -l perl5121delta
/usr/share/perl/5.38/pod/perl5121delta.pod

Your paths and version will differ. On the machine used for this guide, the installed interpreter is Perl 5.38.2 from the Ubuntu perl package, while the installed perl5121delta page is a historical document shipped by perl-doc. That distinction matters: the page describes a 2010 maintenance release, not the behaviour of every later Perl.

2. Read the release boundary first

Display the beginning of the page to establish what it compares:

$ perldoc perl5121delta | sed -n '1,24p'

Expect the name, followed by a statement that the comparison is 5.12.0 to 5.12.1. The page says there were no intentional incompatible changes and no user-visible core-language changes apart from bug fixes. It also tells readers upgrading from an older release to read perl5120delta first. Do not use this one page as a complete migration plan for a 5.10, 5.14 or current-Perl upgrade.

A common distraction is treating the word "delta" as a command option or a package name. It is the name of a Perl documentation page. perl5121delta takes no upgrade action and has no configuration file to edit.

3. Turn the module notes into checks

The 5.12.1 notes mention CGI 3.49, Pod::Simple 3.14 and Safe 2.27, plus a CPANPLUS test-suite fix. Check the modules through the same interpreter you identified in step 1:

$ perl -MCGI -e 'print "CGI $CGI::VERSION\n"'
$ perl -MPod::Simple -e 'print "Pod::Simple $Pod::Simple::VERSION\n"'
$ perl -MSafe -e 'print "Safe $Safe::VERSION\n"'
$ perl -MCPANPLUS -e 'print "CPANPLUS $CPANPLUS::VERSION\n"'

A missing module prints an error and exits non-zero. That is useful evidence, not proof that Perl itself is broken. Modern distributions can split, replace or remove modules, and their versions are not expected to match the versions named in an old release note. On the reference host, CGI, Pod::Simple and Safe are newer than the 5.12.1 versions, while CPANPLUS is not installed in the active module search path.

Record these results with the interpreter version. Checking a module with a different Perl executable can produce a false comparison because each interpreter has its own library paths.

4. Isolate the historical fixes that affect your code

Read the relevant sections without copying the whole page into a ticket:

$ perldoc perl5121delta | sed -n '/Modules and Pragmata/,/Changes to Existing Documentation/p'
$ perldoc perl5121delta | sed -n '/Bug Fixes/,/Platform Specific Notes/p'
$ perldoc perl5121delta | sed -n '/Known Problems/,/Acknowledgements/p'

For application review, concentrate on the fixes with a plausible path into your workload. The page records corrected exporting of is_strict and is_lax from version, a Safe change affecting coderefs returned by reval() and rdo(), and several parser, regular-expression and filetest fixes. It also records a known List::Util::first problem when a lexical $_ is present, and a CPANPLUS crash risk involving an unparseable version string.

Do not turn every listed bug into a test automatically. First search your code and dependency list for the named module, function or syntax. Then add a focused regression test or a dependency review item. A release note is a lead for testing, not a guarantee that your program exercises the affected path.

5. Check the platform notes separately

The page includes build notes for HP-UX, AIX, FreeBSD 7 and VMS. They concern platform-specific Perl builds, including older VMS configuration and a FreeBSD 7 objformat check. They do not describe a Linux runtime switch. If your host is Linux, record that these sections are out of scope and continue with the general module and bug-fix review.

If you are building Perl from source on one of those platforms, use the release page as a pointer to the relevant INSTALL and platform documentation. Do not copy old build flags into a modern Linux build without checking the current build instructions.

6. Record a decision without changing the host

Finish with a small, reproducible evidence bundle:

$ {
    printf 'perl: '
    perl -e 'printf "%vd\n", $^V'
    printf 'perl5121delta: '
    perldoc -l perl5121delta
    printf 'perl executable: '
    command -v perl
}

Attach the module-check output and the names of any application tests you ran. If the host uses a virtual environment, vendor directory or service-specific interpreter, repeat the checks with that exact executable. Avoid "fixing" a version mismatch by placing a random directory in PERL5LIB; that changes resolution order and can hide the real deployment state.