Perl

Resources
Home
Gentoo peach graphicProject
Wikipedia
Warning
For nontrivial changes to this page, please ask / propose the changes on the talk page first! Dilfridge (talk) 14:18, 18 April 2017 (UTC)

TL;DR: Blockers

Users who run into blockers or slot conflicts on a Perl update, should try the following precise commands:

root # emerge -uDNav --with-bdeps=y --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 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 global perl USE flag. It can be enabled (or disabled) globally:

FILE /etc/portage/make.conf
<syntaxhighlight lang="bash">USE="perl"</syntaxhighlight>

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)
Data provided by the Gentoo Package Database · Last update: 2021-03-16 16:42 More information about USE flags

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 @world

In 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 --reallyall

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

root # emerge -uDNav --with-bdeps=y --backtrack=100 --autounmask-keep-masks=y @world
root # perl-cleaner --all

The need for the --with-bdeps=y and --backtrack=100 switches will go away over upcoming portage releases.

Some knowledge

  • Perl modules are installed under e.g. /usr/lib/perl/vendor_perl/5.22.3/. 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-cleaner 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 /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-upgrade

Once this is done, do

root #emerge -ac
root #perl-cleaner --all

Help can be read by:

user $gentoo-perl help gen-upgrade-sets

Details

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

The emerge can be resumed by:

root #emerge --oneshot --ask @perl-upgrade

If you want to store the sets elsewhere, do :

user $ETC_PORTAGE_SETS="/tmp/sets/" gentoo-perl gen-upgrade-sets 5.20 5.22

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

root #cp /tmp/sets/* /etc/portage/sets/*

Wild ways

Warning
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

References

  1. ↑ https://bugs.gentoo.org/show_bug.cgi?id=608168#c1
This article is issued from Gentoo. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.