Perl

Perl-related categories and packages
The Perl language itself is. There're three Perl-related categories:
 * : Libraries in/for Perl, corresponding to, , etc.
 * : Packages in this category are, depending on their versions, modules included in, but also distributed as separete packages. When modules are installed via , they override the counterpart in the core . For the details, see below.
 * : Virtual packages that allow choosing a module between packages and the one contained in the core.

More on perl-core: (Taken from )
 * It allows users to have more update versions of some modules that the core ones.
 * It allows package-based installation, without bumping or patching the core perl.
 * Sometimes these modules get deprecated in newer Perl. Such cases are handled by virtual/perl-*. Search for "Module::Build" for more in-depth stories.

Upgrading Perl
When the official way works, it's fine. See below for more. Unfortunately, it often doesn't work, mainly due to unresolved slot conflicts. There's no "official" way to handle it yet.

It may work by updating "world", i.e., but it will pull in more than necessary. Specifying the depth to 2 or 3 may make the dependency smaller, like this:.

Below we give two recommendable ways to cope with that situation.

The support thread in the forum is found here.

Some knowledge

 * Perl-realted modules are installed under e.g., except those from the core Perl. Notice that the core Perl version number is present. When upgrading Perl, they have to be re-emerged, too.
 * During Perl upgrading, packages that depend on Perl may become unavailable.

In order to upgrade to unstable (~arch) version, you may have to unmask *all*, by running: { echo "### perl keywords" eix '-#C' dev-perl eix '-#C' perl-core eix '-#' virtual/perl- echo dev-lang/perl } >> /etc/portage/package.keywords

app-admin/gentoo-perl-helper
This recent package (appeared in Jan 2017) (git repository) still needs to be tested, but must be far better than. It is written by K. Fredric (kentnl), a Gentoo Perl Project member.

Basic usage
Assume you have 5.20.*, and want to upgrade to 5.22.*.

Now you will have two sets and, (stored in ). Then simply do

Once this is done, do.

Help can be read by:

Details
In, packages' keyword & mask are irrelevant. Simply the specified versions matter. The examples of the version are, , etc, not or. More precisely, they should be the sub-slot number, not atoms' versions.

If portage complains about unsatisfied conflicts, you can try deleting blockers before upgrading:

In the event that portage fails while upgrading Perl, so that some but not all packages are emerged, then update (= trim down) the set :

Now you can resume the emerge by

If you want to store the sets elsewhere, do

A wild way
Caution: There's no guarantee that it works. This prescription is given here becuse of its extreme simplicity.

Taken from, written by hnop.