Use perl5182delta to Check a Perl 5.18.2 Upgrade

You will finish with a small, repeatable check for the Perl 5.18.2 changes: read the installed release notes, identify the fixes that matter to your code, and run harmless probes against the interpreter you actually plan to use. The key boundary is version history. perl5182delta describes the move from Perl 5.18.1 to 5.18.2; it is not a general compatibility report for every modern Perl.

Allow about 15 minutes. 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

Start by recording the versions. This prevents a common upgrade mistake: reading notes for 5.18.2 and assuming that the result describes the Perl binary selected by your service.

$ 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

The manpage says that this release covers differences between 5.18.1 and 5.18.2. If you are coming from 5.18.0, it directs you to perl5181delta first. That sequencing matters: 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.

Do not treat the module version lines as proof that your application uses those modules. Check the module loaded by the application, 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 when it was 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 that 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 it is not by itself proof that 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 used by the application.

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 that performs real work:

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

The exact value is less useful 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 preserve a regression test only if existing code relies on it.

6. Map the remaining fixes to real risk

Some entries are difficult 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 that affected 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. They are not invitations 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. Mark each result as 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 that the path exists.

No rollback is needed for the probes because they are process-local and make no persistent changes. If an actual package upgrade follows, use your distribution's package rollback or snapshot procedure, and schedule the change with the service owner. The release note itself provides no uninstall command and should not be treated as one.