Plan a Perl 5.6 to 5.8 Upgrade with perl58delta

perl58delta will not migrate your code or rebuild a single module for you. It is a release note, so reading it properly means turning it into a written list of code and binary checks before a Perl 5.6 to 5.8 upgrade, which takes about 20 minutes for a small application, plus rebuild time for any XS modules.

The installed page comes from the perl-doc package, version 5.38.2-3.2ubuntu0.6, and describes Perl 5.8.0. The local Perl interpreter is 5.38.2. That distinction matters: the notes describe a historical compatibility boundary, while the commands below confirm what this machine actually does today.

1. Confirm which documentation you are reading

Start with ordinary, read-only checks. None of them need elevated privileges:

$ command -v perl
/usr/bin/perl
$ perl -v | sed -n '1,4p'
This is perl 5, version 38, subversion 2 (v5.38.2) built for x86_64-linux-gnu-thread-multi
$ dpkg-query -W -f='${Package} ${Version}\n' perl-doc
perl-doc 5.38.2-3.2ubuntu0.6
$ man perl58delta

perl58delta takes no operational arguments in this workflow: read it as a record of changes between Perl 5.6.0 and 5.8.0. Changes marked [561] were already present in the 5.6.1 maintenance release, and [561+] means later 5.6.1 work was developed further for 5.8.0.

2. Find the binary compatibility boundary

The first migration decision is whether the application has compiled Perl extensions. Perl 5.8 is not binary-compatible with earlier Perl releases, and the manpage specifically requires XS modules to be recompiled. Pure Perl modules should normally keep working, but test them rather than treating that sentence as a guarantee.

$ perl -MConfig -e 'print "perl=$^V\narch=$Config{archname}\nsitearch=$Config{sitearch}\n"'
perl=v5.38.2
arch=x86_64-linux-gnu-thread-multi
sitearch=/usr/local/lib/x86_64-linux-gnu/perl/5.38.2

Inventory every module that contains compiled code, including application-local extensions and modules loaded by deployment tools. Rebuild them with the target interpreter, then run the application's test suite. On 64-bit platforms the release notes also describe allocator changes, so never copy an old compiled module tree into the new Perl installation.

3. Test the PerlIO and encoding assumptions

PerlIO became the default I/O implementation in 5.8, introducing layers such as :raw, :utf8 and :encoding(). The practical trap is treating a binary stream as text, or assuming that disabling CRLF translation alone makes a stream byte-for-byte raw.

$ perl -MPerlIO -e 'print join("\n", PerlIO::get_layers(*STDOUT)), "\n"'
unix
perlio

The exact layer list is platform-dependent, so treat this as an observation rather than a hard-coded expected output. Test the application's actual files instead, and name text input's encoding deliberately where the data contract requires it:

open my $input, '<:encoding(UTF-8)', $path
    or die "open $path: $!";
open my $binary, '<:raw', $image
    or die "open $image: $!";

Do not add use utf8 as a general Unicode switch. In the 5.8 model, Unicode status belongs mainly to the data; the pragma stays relevant only when the Perl source file itself is written in UTF-8. Check source encoding, input decoding and binary handling as separate concerns.

4. Exercise Unicode and sorting changes

The release notes cover Unicode properties, scripts, regular expressions and I/O, and say that glob() now sorts filenames alphabetically by default. These make good focused regression tests, because they expose assumptions without modifying the system:

$ perl -e 'my $word = "café"; print $word =~ /\p{Letter}+/u ? "unicode-match\n" : "no-match\n"'
unicode-match
$ tmpdir=$(mktemp -d)
$ trap 'rm -rf "$tmpdir"' EXIT
$ touch "$tmpdir/z" "$tmpdir/a"
$ TMPDIR="$tmpdir" perl -e 'print join(" ", glob "$ENV{TMPDIR}/*"), "\n"'
/tmp/tmp.example/a /tmp/tmp.example/z

The temporary directory name will differ; what matters is that the final two path names come out in alphabetical order. The cleanup trap removes only the temporary directory this test created. If an application depends on filesystem order, replace that assumption with an explicit sort and test the expected locale behaviour.

5. Review source-level traps before testing services

Several 5.8 changes can alter code without changing its command line. The release notes call out:

• The new interpreter-thread model.
• Safe signals.
• Integer-preserving arithmetic.
• Better prototype checks.
• Arrays that interpolate in double-quoted strings.

They also list removed or deprecated constructs: the old Thread model, uppercase comparison aliases, tr///C and tr///U, pseudo-hash internals, and unqualified dump().

$ perl -we 'my @names = ("Ada", "Grace"); print "@names\n"'
Ada Grace
$ perl -we 'print "[email protected]\n"'
fred.com at -e line 1.

The second command shows the classic warning-prone email-address trap: an unescaped @ in a double-quoted string is treated as array interpolation. Write fred\@example.com or use a single-quoted string when that is the intended literal text. Run your test suite with warnings enabled, and search source for the deprecated forms named in the page before you change the interpreter.

6. Record the migration decision

Do not convert a release-note list into an automatic edit. Record each item as one of three outcomes: tested and unchanged, changed and covered by a regression test, or not applicable with a reason. For service deployments, run the final test under the same user, environment and input files as production. No command in this guide needs sudo; installing or rebuilding packages belongs to your normal change process.