Perl

The Perl language itself is packaged as. There're three Perl-related categories:


 * : Libraries in / for Perl, corresponding to, , etc. In most cases the package name directly corresponds to a CPAN distribution.
 * : Packages in this category are modules included in, which are also independently packaged on CPAN. When modules are installed via , they override the counterpart in the core . This can be used for selective bugfixes. For the details, see below - but please never manually install any packages with emerge.
 * : Virtual packages that allow choosing a module between packages and the one contained in the core . If you need a specific version of a core package, emerge the corresponding virtual - and the package manager will figure out if a perl-core/ package is needed or not.

More on perl-core :


 * 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.

Normally you do not have to care at all about perl-core packages or virtuals; if you need any specifics there they should be pulled in as dependencies.

Global
Since many packages depend on the perl, Portage is aware of the global perl USE flag. It can be enabled (or disabled) globally:

Package
As always, after adjusting USE flags, be sure to tell Portage to apply the changes to installed packages on the system:

In addition, after changing the  or   use flag setting, you need to re-build all packages installing perl modules or linking to libperl:

Upgrading (major version)
The official way of upgrading Perl, e.g. from Perl 5.22 to Perl 5.24, is upgrading your entire world, and upgrading Perl with it. This is because Portage needs to be able to rebuild packages depending on Perl. If you ask Portage to selectively only upgrade the Perl package itself, it can't do this and the emerge command will fail.

As in all cases when automatic rebuilds are involved, it helps a lot if you do regular updates and regularly run depclean.

The official way
The need for the "--with-bdeps y" and "--backtrack 100" switches will go away over upcoming portage releasese.

Some knowledge

 * Perl modules are installed under e.g. . Note that the core Perl version number is present. When upgrading Perl by a major version, the packages providing these modules have to be re-emerged, too.
 * The same is valid for all packages linking to libperl.
 * The rebuilds 'should' be done automatically by emerge.  exists to do them as well and can catch things missed by emerge (sadly Portage still has some bugs).
 * During Perl upgrade, packages that depend on Perl may become unavailable.
 * No rebuilds are necessary during a point-release update (i.e. from 5.24.0 to 5.24.1).

In order to upgrade your Perl installation to unstable (~arch) version on an otherwise stable system, add the following text to : dev-lang/perl perl-core/* virtual/perl-* Perl itself, the perl-core packages and the Perl virtuals 'must' have the same, consistent status (either all stable or all ~arch). What setting you use for dev-perl packages does not matter at all.
 * 1) use Perl from ~arch

app-admin/gentoo-perl-helpers
This recent package (git repository), written by Kent Fredric (kent\n) intends to provide support for selective updates. Thus it will be very useful for people using, e.g., puppet for automation of installs. It may also help in other cases when gets "stuck".

Although it's only "~amd64 ~arm64 ~x86" as of Mar 2017, it's likely to work for any architecture, only needing basic utils like bash, coreutils, etc.

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 and 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 (the same command as the first time generation):

The emerge can be resumed by:

If you want to store the sets elsewhere, do :

To use it later, don't forget to do this:

A wild way
Version 1: this emulates the old behaviour before Portage could do automated rebuilds. Possible if you want to update Perl and only Perl.

Version 2: this is if you want to update your world, but emerge seems to be completely stuck with a lot of Perl-related errors. Warning 1: you may temporarily open up security vulnerabilities on your system while the update process is running. Warning 2: you should be familiar with revdep-rebuild.