Trace Perl Core Modules and Releases with corelist

corelist answers one packaging question fast: was this Perl module shipped in that release, and which version? It also tells you where the module is maintained. The command reads the installed Module::CoreList data. It does not install modules, inspect every Perl installation on the machine, or change system state.

These examples were checked on Ubuntu's perl package version 5.38.2-3.2ubuntu0.6. The local manual is dated 14 September 2026 and identifies Perl 5.38.2. Allow about 10 minutes for the first pass. You need a shell and the corelist command; ordinary user privileges are enough.

1. Confirm the command and its data set

Start by checking the executable and the Perl package version. This prevents a common trap: corelist reports the releases known to its installed Module::CoreList, not necessarily the newest Perl release available upstream.

command -v corelist
perl --version | sed -n '1,2p'
dpkg-query -W -f='${Package} ${Version}\n' perl
corelist -v

The last command lists the Perl release versions in the local data. On this machine the package is Perl 5.38.2. If your output ends at a different release, use that value in the examples below rather than assuming that the installed command knows about newer releases.

2. Check when a module entered core

Give a module name without its .pm suffix. The default answer is the first known release by module version, which is usually the useful starting point.

corelist File::Spec

On the checked system the result includes:

File::Spec was first released with perl 5.00405

To test a specific module version, add it as the next argument:

corelist File::Spec 0.89

This reports that File::Spec 0.89 was released with Perl 5.8.6. A version that was not part of the known core data produces a clear negative result, but do not read that as proof that the module cannot be installed from CPAN.

Checkpoint: distinguish core from installed

corelist answers a historical core-list question. It does not prove that a module is installed in the Perl you will run, and it does not compare two directories in @INC. For the local interpreter, use a separate read-only check:

perl -MFile::Spec -e 'print "$File::Spec::VERSION\n"'

If that command fails, the module is unavailable to that interpreter even if corelist File::Spec says it was shipped with some Perl release.

3. Filter by Perl release

Use -v with a Perl version to ask which module version was recorded for that release. The manual accepts the compact form used in Perl's $], such as 5.008008, and also new-style versions when the version module is available.

corelist -v 5.38.2 File::Spec
corelist -v 5.8.8 B
corelist -v 5.8.8 /^B::/

The first command reports File::Spec 3.88 for Perl 5.38.2. The second reports B 1.09_01. The regular expression form finds every matching module, so the third command prints the B:: family recorded for Perl 5.8.8. Regular expressions must be written between slashes; an ordinary name is treated as one module.

To see every known release of a module, use -a:

corelist -a Unicode | sed -n '1,12p'

That is useful when a dependency changed alongside Perl. The special module name Unicode also displays the Unicode Character Database version bundled with each requested Perl release.

4. Inspect release dates and utilities

-r lists Perl releases and their dates. Add one release to narrow the result:

corelist -r 5.38.2

On the checked system this includes Perl v5.38.2 was released on 2023-11-29. This is a date from the local core data, not a live release lookup.

Utilities have a separate data set. Ask when a named utility first appeared:

corelist --utils perl

To list the utilities bundled with one Perl release, combine --utils and -v. Named utilities are ignored in this form:

corelist --utils -v 5.38.2 | sed -n '1,12p'

If your question is about language syntax rather than a module, use --feature or its short form -f:

corelist --feature say

The checked output identifies the Perl 5.9.5 say feature bundle.

5. Compare two Perl releases

For a migration review, compare two Perl versions directly:

corelist --diff 5.36.0 5.38.0 | sed -n '1,24p'

The command prints a human-readable table of module changes. Its manual explicitly warns that the format may change and is intended for people, not scripts. Do not parse this output as a stable machine interface. For automation, use the Module::CoreList Perl API instead.

A diff is evidence for a review, not a complete compatibility test. Check your application's dependency declarations, run its test suite against the target Perl, and look for modules that moved from core to an external distribution.

6. Check upstream ownership

Use --upstream, or -u, for a module's recorded maintenance location:

corelist --upstream File::Spec

The local data reports the first core release and may show upstream: undef or bug tracker: unknown. Treat missing ownership metadata as missing metadata, not as a claim that nobody maintains the module. The command does not contact CPAN or open the bug tracker.

Common traps and safe boundaries

There is no state to undo because these commands only read local Perl metadata. If an output looks surprising, repeat the query with the explicit Perl release and check the installed package version before drawing a conclusion.

Done means