Use perl5182delta to Check a Perl 5.18.2 Upgrade

Reading a fix in perl5182delta does not tell you whether your service's Perl actually has it, and this fifteen-minute check closes that gap. Read the installed release notes, identify the fixes that matter to your code, and run harmless probes against the interpreter you plan to use. perl5182delta describes the move from Perl 5.18.1 to 5.18.2, not a general compatibility report for every modern Perl.

You need a shell, the perl-doc package, and a Perl interpreter. The examples only print values or match strings. They do not install modules, edit files, restart services or change the interpreter. Run them as an ordinary user.

1. Confirm the interpreter and documentation package

Record the versions first, so you never assume notes for 5.18.2 describe the Perl binary your service actually selects:

$ perl -e 'print "$^V\n"'
v5.38.2
$ dpkg-query -W -f='${Package} ${Version}\n' perl-doc
perl-doc 5.38.2-3.2ubuntu0.6

Your output may differ. The local machine used for this guide has Perl v5.38.2 and perl-doc 5.38.2-3.2ubuntu0.6. If perl-doc is absent, stop here and obtain the documentation through your normal package-management process; do not copy a random release note into a system directory.

2. Read the 5.18.2 delta

Use perldoc for a terminal-friendly copy of the installed document:

$ perldoc perl5182delta

This release covers differences between 5.18.1 and 5.18.2. Coming from 5.18.0, read perl5181delta first: a delta document is a narrow change log, not a complete list of changes since an arbitrary starting point. For a quick inventory, look for these sections:

• Module updates to B, B::Concise, English and File::Glob.
• Bug fixes for B::CV::GV, Unicode character classes, ->SUPER::method with AUTOLOAD, and -bareword under the strict and integer pragmata.
• Lower-level fixes for PerlIO layer duplication, long identifiers, keyword plugins and dynamic regular expressions.

The module version lines are not proof your application uses those modules. Check the module the application actually loads, and check the interpreter path separately.

3. Test the regular-expression fixes without changing state

The release notes mention two regular-expression regressions. The first affected a negated ASCII character class combined with another qualifier. This probe should match an accented Latin-1 character:

$ perl -e 'print "match\n" if "\x{e9}" =~ /[[:^ascii:]a]/'
match

The second concerned a compiled expression stored in a scalar and then used with the /p modifier. A simple match confirms the stored expression is accepted:

$ perl -e 'my $r = qr/a/; print "matched\n" if "a" =~ /$r/p'
matched

A blank result or a non-zero exit status is worth investigating, but is not by itself proof the interpreter is affected by a 5.18.2 bug. Locale, source encoding, warnings and later Perl changes can alter the result. Re-run the probe with the exact Perl executable and environment the application uses.

4. Exercise SUPER and AUTOLOAD deliberately

Perl 5.18.0 changed the lookup path for ->SUPER::method when the method was supplied by AUTOLOAD. This short program makes the intended inheritance relationship visible:

$ perl -e 'package Base; sub AUTOLOAD { print "base\n" } package Child; our @ISA = ("Base"); sub call { shift->SUPER::missing() } Child->call()'
base

The expected line is base. This is a read-only test of method dispatch; it does not load a module or modify the package after the process exits. If your code uses AUTOLOAD, add a focused test like this to the application's test suite, then run the suite under both the old and new interpreter during a planned upgrade.

Keep the failure narrow. A missing method, an unexpected package name or an altered @ISA can look like a Perl regression while being an application defect. Print the package and method you are testing before changing production code.

5. Check pragma-sensitive barewords safely

The notes record a regression where -bareword was rejected when strict and integer were used together. Test the syntax in a disposable process, not in a script performing real work:

$ perl -Mstrict -Minteger -e 'my $x = -bareword; print "$x\n"'
0

The exact value matters less than the exit status and the absence of a compile error. -bareword is a deliberately unusual construct, so do not introduce it merely because this probe succeeds. Search your codebase for the construct and keep a regression test only if existing code relies on it.

6. Map the remaining fixes to real risk

Some entries are hard to reproduce with a safe one-liner. The B::CV::GV correction restored a B::SPECIAL result in a null-CvGV case and fixed a regression affecting Devel::Cover. The document also records a possible null-pointer crash in PerlIO layer duplication, a buffer overflow involving very long identifiers, and an assertion failure involving keyword plugins and pad operations.

These are reasons to upgrade a vulnerable 5.18.1 installation and run its existing test suite, not an invitation to manufacture crash cases on a production host. If you use Devel::Cover, custom keyword plugins, threaded builds, unusual PerlIO layers or generated identifiers, make those areas explicit in your upgrade test plan.

For module-level changes, inspect the versions loaded by the target interpreter:

$ perl -MB -e 'print "$B::VERSION\n"'
$ perl -MB::Concise -e 'print "$B::Concise::VERSION\n"'
$ perl -MFile::Glob -e 'print "$File::Glob::VERSION\n"'

Blank or unexpected output needs investigation against the module's documentation and the interpreter's @INC. Do not infer a module version from the release-note heading alone.

7. Record an upgrade decision

Put the interpreter version, package version, probe results and application tests in the change record, and mark each result passed, failed or not applicable. If a service uses a different Perl path, run the same commands through that path, for example /opt/perl/bin/perl, after verifying the path exists.