Perl
For nontrivial changes to this page, please ask / propose the changes on the talk page first! Dilfridge (talk) 14:18, 18 April 2017 (UTC)
Perl is a general purpose interpreted programming language with a powerful regular expression engine.
TL;DR: Blockers
Users who run into blockers or slot conflicts on a Perl update, should try the following precise commands:
root #emerge -uDNav --backtrack=100 --autounmask-keep-masks=y @world
root #perl-cleaner --all
This should fix 99% of all problems.
Introduction
The Perl language itself is packaged as dev-lang/perl. There're three Perl-related categories:
- dev-perl: Libraries in / for Perl, corresponding to dev-java, dev-python, etc. In most cases the package name directly corresponds to a CPAN distribution.
- perl-core: Packages in this category are modules included in dev-lang/perl, which are also independently packaged on CPAN. When modules are installed via perl-core, they override the counterpart in the core dev-lang/perl. This can be used for selective bugfixes. For the details, see below - but please never manually install any perl-core packages with emerge.
- virtual/perl-*: Virtual packages that allow choosing a module between perl-core/ packages and the one contained in the core dev-lang/perl. 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[1]:
- 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 [1] 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.
Installation
USE flags
Global
Since many packages depend on the perl, Portage is aware of the USE=perl USE flag. It can be enabled (or disabled) globally:
/etc/portage/make.confUSE="perl"
This is typically only required if carrying out a lot of Perl development locally.
Package
USE flags for dev-lang/perl Larry Wall's Practical Extraction and Report Language
berkdb
|
Add support for sys-libs/db (Berkeley DB for MySQL) |
debug
|
Enable extra debug codepaths, like asserts and extra output. If you want to get meaningful backtraces see https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Backtraces |
doc
|
Add extra documentation (API, Javadoc, etc). It is recommended to enable per package instead of globally |
gdbm
|
Add support for sys-libs/gdbm (GNU database libraries) |
ithreads
|
Enable Perl threads, has some compatibility problems |
minimal
|
Install a very minimal build (disables, for example, plugins, fonts, most drivers, non-critical features) |
quadmath
|
Enable 128bit floating point arithmetic via libquadmath |
As always, after adjusting USE flags, be sure to tell Portage to apply the changes to installed packages on the system:
root #emerge --ask --update --changed-use --deep --autounmask-keep-masks=y @worldIn addition, after changing the ithreads or debug use flag setting, you need to re-build all packages installing perl modules or linking to libperl:
root #perl-cleaner --reallyallUpgrading (major version)
The official way of upgrading Perl, e.g. from Perl 5.32 to Perl 5.34, 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
root #emerge -uDNav --backtrack=100 --autounmask-keep-masks=y @world
root #perl-cleaner --all
The need for the --backtrack=100 switches will go away over upcoming Portage releases.
Some knowledge
- Perl modules are installed under e.g. /usr/lib/perl5/vendor_perl/5.34/. 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.
app-admin/perl-cleanerexists 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 /etc/portage/package.accept_keywords:
# use Perl from ~arch 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.
app-admin/gentoo-perl-helpers
This recent package app-admin/gentoo-perl-helpers (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 $ emerge -auDN @world gets "stuck".
Although it's only ~amd64 ~arm64 ~x86 as of December 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.*.
root #gentoo-perl gen-upgrade-sets 5.20 5.22 # NOT 5.20.1. See below for more.Now you will have two sets perl-upgrade and perl-cleanup, (stored in /etc/portage/sets). Then simply do
root #emerge --oneshot --ask @perl-upgradeOnce this is done, do
root #emerge -ac
root #perl-cleaner --all
Help can be read by:
user $gentoo-perl help gen-upgrade-setsDetails
In gentoo-perl gen-upgrade-sets, packages' keyword and mask are irrelevant. Simply the specified versions matter. The examples of the version are 5.20, 5.22, etc, not 5.22.3_rc4 or 5.24.1_rc4. 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:
root #emerge --unmerge @perl-cleanup
root #emerge --oneshot --ask @perl-upgrade
In the event that portage fails while upgrading Perl, so that some but not all packages are emerged, then update (= trim down) the set @perl-upgrade (the same command as the first time generation):
root #gentoo-perl gen-upgrade-sets 5.20 5.22The emerge can be resumed by:
root #emerge --oneshot --ask @perl-upgradeIf you want to store the sets elsewhere, do :
user $ETC_PORTAGE_SETS="/tmp/sets/" gentoo-perl gen-upgrade-sets 5.20 5.22To use it later, don't forget to do this:
root #cp /tmp/sets/* /etc/portage/sets/*Wild ways
There's no guarantee that these recipes work. Please read the text below carefully.
Version 1: this emulates the old behaviour before Portage could do automated rebuilds. Possible if you want to update Perl and only Perl.
root #emerge --ask --oneshot --ignore-built-slot-operator-deps=y dev-lang/perl
root #perl-cleaner --all
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.
root #emerge --ask --unmerge 'perl-core/*' 'virtual/perl-*'
root #emerge -uDNav --ignore-built-slot-operator-deps=y @world
root #perl-cleaner --all
root #revdep-rebuild