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.
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
The official way of upgrading Perl, e.g. from Perl 5.36 to Perl 5.38, 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.
If this fails, please check your world file for packages which cannot be updated/reinstalled because they've been removed or are in some way masked.
Some knowledge
- Perl modules are installed under e.g. /usr/lib/perl5/vendor_perl/5.36/. 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.36.0 to 5.36.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.
External Resources
- Why Perl? — a detailed but approachable article on the empowering nature of Perl while still remaining honest about its limitations.