Portal:Linux

Linux Distributions and Perl

Perl has been closely associated with Linux since the early years of the operating system. Linux inherited much of its userland culture from Unix, and Perl fit naturally into that world: text files, log files, shell scripts, package metadata, system administration, web hosting, mail processing, build systems, and automation. For much of Linux history, a user could reasonably assume that `/usr/bin/perl` existed on a normal installed system.

That assumption is still often true, especially on Debian-family systems and traditional full installations. However, it is less universal than it once was. Minimal cloud images, container images, embedded distributions, and some enterprise Linux installations may omit Perl unless another package depends on it. Modern Linux Perl history is therefore a story of both ubiquity and reduction: Perl remains widely packaged and widely used, but fewer systems treat a full Perl environment as automatically necessary.

Perl.org summarizes the traditional Unix/Linux situation simply: Perl is included on Unix/Linux systems, although it may not be the latest version.<ref>Perl.org, “Perl Download,” https://www.perl.org/get.html, accessed July 3, 2026.</ref>

System Perl and user Perl

On Linux, the most important distinction is between system Perl and user Perl.

System Perl is the Perl interpreter provided by the Linux distribution. It is installed through the system package manager, such as `apt`, `dnf`, `zypper`, `pacman`, `apk`, `emerge`, or `pkgtool`. It may be required by operating-system tools, package scripts, build scripts, or other installed packages. Its modules are usually installed in vendor-controlled directories and tracked by the package manager.

User Perl is a Perl interpreter or module tree installed by the user or application owner. It may be managed with tools such as `perlbrew`, `plenv`, `local::lib`, `cpanm`, or an application-specific dependency system. A user Perl is safer for application development because it avoids overwriting or confusing modules needed by the operating system.

This distinction matters because installing CPAN modules directly into the system Perl can conflict with distribution packages. On production Linux systems, the safest practice is usually:

• use distribution packages for system Perl modules when possible;
• use a separate local Perl for application-specific CPAN modules;
• avoid replacing the distribution’s `/usr/bin/perl`;
• do not assume the full upstream Perl core is present when only a minimal Perl package is installed.

Overview by distribution family

Debian

Perl is included by default through perl-base. Debian is one of the strongest modern examples of Perl as an essential system component. Debian manages Perl through apt, dpkg, Debian Perl Policy, and lib*-perl packages.

Ubuntu and Debian derivatives

Ubuntu, Linux Mint, Pop!_OS, Raspberry Pi OS, and many related distributions usually inherit Debian’s Perl packaging model. Normal installations usually include Perl through perl-base, although a fuller Perl environment may require additional packages.

Slackware

Slackware includes Perl on a traditional full installation. This reflects the older Unix-like expectation that Perl is part of a useful general-purpose system.

Fedora

Fedora has strong Perl packaging, but Perl is split into runtime, core, documentation, and development packages. Full systems often have Perl installed, while minimal systems may require explicit installation of perl-interpreter or perl-core.

RHEL, Rocky Linux, AlmaLinux, and CentOS Stream

Modern RHEL-family minimal systems should not be assumed to include Perl. Since RHEL 8, Perl is not included in the default RPM buildroot, so packages that use Perl must declare it explicitly.

openSUSE and SUSE Linux Enterprise

Perl is commonly available and well packaged through RPM, zypper, and the Open Build Service. Whether Perl is installed by default depends on the selected installation pattern or system role.

Arch Linux and derivatives

Perl is available in the core repository and is commonly installed through dependencies, especially on development systems. Arch’s rolling-release model means Perl module rebuilds may be needed after major Perl upgrades.

Gentoo

Gentoo manages Perl through Portage, including dev-lang/perl and dev-perl/* packages. Gentoo also has tools such as perl-cleaner to help rebuild Perl modules after interpreter upgrades.

Alpine Linux

Alpine does not include Perl in its smallest default systems. Perl is available with apk add perl, but Alpine’s minimal BusyBox/musl design means Perl must usually be installed explicitly.

NixOS and Guix System

Perl is available, but not assumed globally. These systems emphasize declarative package and environment management, so Perl is installed or declared where it is needed.

Debian: the strongest Linux system-Perl tradition

Debian is the clearest modern example of Perl as a base-system language. Debian’s Perl Policy states that `perl-base` contains the Perl binary and a basic set of modules. It also states that because Perl has long been part of the essential set and is used by package maintainer scripts, `perl-base` must be priority `required` and marked as `essential`.<ref>Debian Project, “Perl Policy, Chapter 2,” https://www.debian.org/doc/packaging-manuals/perl-policy/ch-perl.html, accessed July 3, 2026.</ref>

This means Debian does not merely package Perl as an optional programming language. It treats a minimal Perl runtime as part of the core operating environment. Debian’s `perl-base` package description says it provides a Perl interpreter and the small subset of the standard run-time library required to perform basic tasks.<ref>Debian Packages, “perl-base,” https://packages.debian.org/sid/perl-base, accessed July 3, 2026.</ref>

Debian separates Perl into multiple layers:

• `perl-base` — minimal essential Perl system;
• `perl` — fuller interpreter package;
• `perl-modules-*` — core Perl modules;
• `perl-doc` — documentation;
• `lib*-perl` — packaged CPAN modules;
• `site` directories — locally installed modules;
• `vendor` directories — distribution-packaged modules.

This structure reflects Debian’s emphasis on policy, reproducibility, dependencies, and package-manager ownership.

Debian is also important because it has a large Perl packaging community. Many CPAN modules are available as Debian packages with names such as `libdbi-perl`, `libwww-perl`, `libjson-xs-perl`, and so on. This makes Debian one of the easiest Linux distributions on which to maintain Perl applications using only distribution packages.

Historically, Debian’s Perl integration helped preserve Perl’s status as a normal Unix tool. A Debian administrator could expect Perl to be present for package scripts, system scripts, and automation even if the full development environment was not installed.

Ubuntu and Debian derivatives

Ubuntu inherits much of Debian’s Perl packaging model. Ubuntu is based on Debian, and Ubuntu systems use the same general `apt` and `dpkg` package model. Ubuntu package listings for `perl-modules-*` show dependency on `perl-base`, and Ubuntu systems provide `perl-base` as the minimal Perl layer.<ref>Ubuntu Packages, “perl-modules-5.40,” https://packages.ubuntu.com/resolute/perl-modules-5.40, accessed July 3, 2026.</ref>

Normal Ubuntu server and desktop systems generally have `/usr/bin/perl` available because of this inherited Debian model. Ubuntu derivatives such as Linux Mint, Pop!_OS, elementary OS, and many others usually inherit the same basic Perl packaging approach.

This is why Perl scripts have often been portable across Debian and Ubuntu systems. A short system-administration script using core Perl features is likely to run without installing a separate interpreter.

However, there is still an important distinction between `perl-base` and a full Perl development environment. `perl-base` is enough for basic system use, but a real Perl application may require the full `perl` package, development tools, XS module dependencies, database bindings, SSL libraries, or CPAN modules.

For serious Perl development on Ubuntu or Debian derivatives, users should usually install distribution packages first, then use a local Perl or local module tree when CPAN versions are needed.

Linux Mint, Pop!_OS, Raspberry Pi OS, and other Debian descendants

Many popular desktop and small-system distributions are derived from Debian or Ubuntu. Linux Mint, Pop!_OS, KDE neon, elementary OS, Zorin OS, and Raspberry Pi OS generally inherit Debian-style Perl packaging. In practice, this means Perl is usually present on normal installations, at least in minimal `perl-base` form.

This inheritance matters because Debian-family systems are widely used on desktops, servers, virtual machines, cloud systems, and single-board computers. Perl’s default presence on these systems helped preserve its reputation as a portable Unix scripting language.

Raspberry Pi OS is historically interesting because many Raspberry Pi users learn scripting and automation on it. Even when Python is emphasized educationally, Perl is still available through the Debian package base and can be used for text processing, GPIO-adjacent scripts, web utilities, logs, and administrative tasks.

Slackware: traditional full-system Perl

Slackware is one of the oldest surviving Linux distributions and has long maintained a traditional Unix-like identity. In the Slackware model, a recommended full installation provides a broad and coherent set of packages rather than a small dependency-resolved minimal core.

Slackware includes Perl as a normal package in its distribution. Slackware’s package description for Perl calls it Larry Wall’s “Practical Extraction and Report Language” and describes it as optimized for scanning text files, extracting information, and printing reports, as well as useful for system-management tasks.<ref>Slackware Packages, “perl-5.34.0-x86_64-1.txz,” https://packages.slackware.com/?p=perl-5.34.0-x86_64-1.txz&r=slackware64-15.0, accessed July 3, 2026.</ref>

Slackware is important to Perl history because it represents the older assumption that a Unix-like system should come with practical tools. Perl fits naturally into that model. It is not separated into dozens of micro-packages to the same degree as some other distributions; instead, Slackware tends to ship a usable upstream-style package set.

For Perl users, Slackware’s simplicity has advantages and disadvantages. The advantage is that Perl is part of a broad full installation and behaves in a traditional Unix way. The disadvantage is that Slackware does not use automatic dependency resolution in the same way Debian, Fedora, or openSUSE do. Users installing additional Perl modules must pay attention to dependencies themselves or use community tools.

Fedora

Fedora has a strong Perl packaging ecosystem, but it does not treat Perl in exactly the same way Debian does. Fedora splits Perl into multiple packages. The `perl-interpreter` package provides the standalone `/usr/bin/perl` interpreter required for handling Perl scripts, but it does not provide all Perl modules or tools. Fedora’s package page says users should install `perl` for the upstream core modules, `perl-devel` for headers, `perl-utils` for utilities, and `perl-debugger` for the debugger.<ref>Fedora Packages, “perl-interpreter,” https://packages.fedoraproject.org/pkgs/perl/perl-interpreter/, accessed July 3, 2026.</ref>

Fedora’s developer documentation recommends installing `perl-core` for a full Perl environment, saying that it brings in the language interpreter and the core modules recommended by upstream Perl.<ref>Fedora Developer Portal, “Perl installation,” https://developer.fedoraproject.org/tech/languages/perl/perl-installation.html, accessed July 3, 2026.</ref>

Fedora is historically important because it reflects the RPM-world approach to Perl: split packaging, generated dependencies, module provides, and explicit package ownership. Perl modules are usually packaged as RPMs, and RPM dependency metadata can refer to Perl modules by names such as `perl(Module::Name)`.

On a full Fedora Workstation or Server installation, Perl may be present because other packages depend on it. But Fedora should not be treated as guaranteeing a complete Perl environment on every minimal image. Developers who need Perl should declare or install the appropriate package rather than assume it.

Red Hat Enterprise Linux, Rocky Linux, AlmaLinux, and CentOS Stream

The Red Hat Enterprise Linux family has moved further away from the old assumption that Perl is always installed. RHEL still packages and supports Perl, but modern RHEL minimal environments may not include it by default.

Red Hat’s RHEL 9 packaging documentation states that since RHEL 8, Perl is not included in the default buildroot. Therefore, RPM packages that include Perl scripts must explicitly declare a Perl build dependency through `BuildRequires`.<ref>Red Hat, “Red Hat Enterprise Linux 9: Packaging and distributing software,” section 6.8, https://docs.redhat.com/es/documentation/red_hat_enterprise_linux/9/pdf/packaging_and_distributing_software/red_hat_enterprise_linux-9-packaging_and_distributing_software-en-us.pdf, accessed July 3, 2026.</ref>

This is one of the most important modern Linux Perl changes. It shows that enterprise Linux is no longer assuming Perl as part of the minimal development environment. If a package uses Perl, it must say so.

Rocky Linux, AlmaLinux, Oracle Linux, and CentOS Stream generally inherit the RHEL packaging model. Perl is available through `dnf`, and many Perl modules are available through distribution repositories or EPEL, but a minimal enterprise Linux install should not be assumed to have `/usr/bin/perl`.

This affects portability. A Perl script that runs on Debian by default may fail on a new minimal RHEL-family server until Perl is installed:

dnf install perl-interpreter

or, for a fuller environment:

dnf install perl-core

This does not mean Red Hat systems are anti-Perl. It means they have made Perl explicit rather than implicit.

openSUSE and SUSE Linux Enterprise

openSUSE and SUSE Linux Enterprise have long supported Perl through RPM packages and the Open Build Service. The openSUSE software site describes `perl-base` as containing the Perl binary and basic modules, and describes Perl as useful for scanning text files, extracting information, printing reports, and system-management tasks.<ref>openSUSE Software, “perl-base,” https://software.opensuse.org/package/perl-base, accessed July 3, 2026.</ref>

openSUSE also has dedicated Perl packaging documentation. The openSUSE “Packaging Perl” page describes the process of building Perl software packages for openSUSE and others using the Open Build Service.<ref>openSUSE Wiki, “Packaging Perl,” https://en.opensuse.org/openSUSE%3APackaging_Perl, accessed July 3, 2026.</ref>

SUSE’s Perl story is important because of the Open Build Service. OBS makes it possible to build packages for multiple SUSE and non-SUSE targets, and Perl modules can be packaged through SUSE RPM macros and helper tools. This places Perl inside a strong cross-distribution packaging system.

Whether Perl is installed by default depends on the selected product, installation pattern, and role. A full openSUSE desktop or server environment may include Perl through dependencies, but a minimal installation or container should be checked explicitly.

Arch Linux and Arch derivatives

Arch Linux packages Perl in the `core` repository. The Arch package page for `perl` lists Perl 5.42.2 in `core` and shows that many packages require it, including development tools such as `autoconf` and `automake`.<ref>Arch Linux Packages, “perl,” https://archlinux.org/packages/core/x86_64/perl/, accessed July 3, 2026.</ref>

Arch’s installation model is more user-driven than Debian’s or Ubuntu’s. The `pacstrap` installation tool says that if no packages are specified, it defaults to the `base` group.<ref>Arch Linux, “pacstrap.in,” https://github.com/archlinux/arch-install-scripts/blob/master/pacstrap.in, accessed July 3, 2026.</ref> However, Arch users explicitly choose what to install, and Perl is best understood as a core repository package that is commonly pulled in by real systems, especially systems with development tools.

Arch is also important because it is a rolling-release distribution. Perl upgrades can affect binary Perl modules and AUR packages. When Perl’s version or ABI changes, Perl XS modules may need rebuilding. This is not unique to Arch, but rolling releases make such changes more visible.

Arch’s Perl packaging culture generally favors installing Perl modules through `pacman` or the AUR when possible, instead of mixing arbitrary CPAN installs into the system Perl. This matches the general Linux best practice: keep system package management and local CPAN development separate.

Arch derivatives such as Manjaro, EndeavourOS, and Garuda usually inherit this model. Perl may be present because of dependencies, especially on full desktop installations, but minimal systems should not assume it unless it is installed or pulled in.

Gentoo

Gentoo provides Perl as `dev-lang/perl`. The Gentoo package site lists current Perl versions including Perl 5.42.2 and newer release-candidate work.<ref>Gentoo Packages, “dev-lang/perl,” https://packages.gentoo.org/packages/dev-lang/perl, accessed July 3, 2026.</ref>

Gentoo has a dedicated Perl Project. Gentoo’s Perl Project package listing includes hundreds of Perl-related packages and tools such as `gentoo-perl-helpers`, `perl-cleaner`, and `g-cpan`.<ref>Gentoo Packages, “Perl Project,” https://packages.gentoo.org/maintainer/perl%40gentoo.org, accessed July 3, 2026.</ref>

Gentoo is historically interesting because it builds software from source through Portage. Perl is not merely installed as a binary package; it is compiled and integrated through ebuilds. Perl modules live in categories such as `dev-perl/*`, and Gentoo has special tools to manage version transitions.

The most important Gentoo-specific Perl tool is `perl-cleaner`. When Perl is upgraded, compiled Perl modules may need to be rebuilt against the new interpreter. Gentoo’s `perl-cleaner` helps identify and rebuild old Perl-module installations. This makes Gentoo one of the clearest examples of Perl as a deeply package-managed language rather than just a scripting binary.

For users, the practical rule is simple: use Portage-managed Perl modules when possible, and be cautious about installing CPAN modules outside Portage on a system Perl.

Alpine Linux

Alpine Linux is an important counterexample to the old assumption that Perl is everywhere. Alpine is designed for small size, containers, embedded systems, and minimal environments. Alpine’s wiki says Alpine is built around musl libc and BusyBox, and that Alpine comes with BusyBox by default to minimize footprint.<ref>Alpine Linux Wiki, “BusyBox,” https://wiki.alpinelinux.org/wiki/BusyBox, accessed July 3, 2026.</ref>

Perl is available in Alpine’s package repositories, but it is not part of the tiny default environment. Alpine’s package database lists `perl` as “Larry Wall’s Practical Extraction and Report Language,” with version 5.42.2-r0 in the edge branch.<ref>Alpine Linux Packages, “perl,” https://pkgs.alpinelinux.org/package/edge/main/x86/perl, accessed July 3, 2026.</ref>

On Alpine, Perl is installed with:

apk add perl

Alpine matters because it is widely used in containers. Many developers who assume `/usr/bin/perl` exists on “Linux” discover that it does not exist in an Alpine container. This is a major practical shift from the older Unix norm.

Perl applications can run well on Alpine, but native XS modules may require development packages, compilers, headers, and attention to musl-vs-glibc differences.

Void Linux

Void Linux is an independent Linux distribution using the XBPS package system and runit by default. Void’s base system is intentionally lean. Perl is available as a package, but it should not be assumed in the smallest base installation unless a selected package depends on it.

Void is relevant because it represents a newer minimalist distribution culture. Like Alpine and Arch, it encourages explicit package selection. Perl is available, but users should install it intentionally when they need it.

This is different from Debian’s philosophy, where a minimal Perl runtime is part of the essential package set.

NixOS and Guix System

NixOS and Guix System are also important to the modern Perl story, even though they do not focus on default Perl availability. These systems are declarative and reproducible. Software is not assumed globally in the same way it is on traditional Unix systems.

On NixOS, a user normally declares Perl as a package in a system or user environment. On Guix System, Perl is likewise available through the package system but must be included explicitly.

This model is philosophically different from the classic Unix assumption. Instead of asking, “Does Linux have Perl by default?”, the NixOS or Guix answer is, “Declare Perl where you need Perl.” That makes Perl less invisible but more reproducible.

Container images and cloud images

Modern container and cloud images changed Perl’s default-availability story. A traditional full Linux server often includes Perl. A minimal container image often does not.

This distinction is now critical. A script beginning with:

#!/usr/bin/perl

may run immediately on Debian, Ubuntu, or Slackware, but fail on Alpine, a minimal RHEL-family image, or a stripped-down OCI image. Even when `/usr/bin/perl` exists, only a minimal module set may be available.

For container work, the correct approach is to declare Perl explicitly in the image:

RUN apt-get update && apt-get install -y perl

or:

RUN dnf install -y perl-interpreter

or:

RUN apk add --no-cache perl

For production Perl applications, the official Perl container images or purpose-built distribution images are often a better choice than relying on a random base image.

Linux package naming patterns for Perl modules

Each Linux family has its own Perl module naming conventions.

Debian and Ubuntu usually use:

libfoo-bar-perl

for a CPAN module named `Foo::Bar`.

Fedora, RHEL, and openSUSE often use:

perl-Foo-Bar

and RPM metadata can express dependencies as:

perl(Foo::Bar)

Arch usually uses:

perl-foo-bar

Gentoo uses categories such as:

dev-perl/Foo-Bar

Alpine often uses:

perl-foo-bar

These naming patterns matter when converting installation instructions across distributions. A CPAN module name is not usually the same as the Linux package name.

Why Linux kept Perl for so long

Linux distributions kept Perl widely available because Perl solved real system problems. It was portable, mature, fast enough for administration, excellent with text, and backed by CPAN. Many maintainers used Perl for scripts before Python became dominant in distribution tooling.

Perl was especially useful for:

• package maintainer scripts;
• build tools;
• log analysis;
• mail processing;
• web hosting;
• CGI scripts;
• system administration;
• documentation tools;
• database maintenance;
• monitoring scripts;
• text conversion;
• installer and upgrade helpers.

Perl’s presence on Linux was not accidental. It was part of the operating environment that made Linux useful as a server and development platform.

Why some Linux systems no longer assume Perl

Several trends weakened Perl’s default presence:

• minimal cloud images reduced default packages;
• containers encouraged tiny base images;
• Python became more common for distribution tooling;
• shell scripts replaced some Perl scripts;
• Go and Rust produced self-contained administrative tools;
• enterprise packaging began requiring explicit build dependencies;
• embedded and container distributions prioritized size over convenience;
• security-conscious systems reduced unnecessary interpreters.

This does not mean Perl disappeared. It means Perl became more explicitly managed.

The change is especially visible in the RHEL family, where Red Hat documents that Perl is no longer in the default buildroot starting with RHEL 8.<ref>Red Hat, “Red Hat Enterprise Linux 9: Packaging and distributing software,” section 6.8, https://docs.redhat.com/es/documentation/red_hat_enterprise_linux/9/pdf/packaging_and_distributing_software/red_hat_enterprise_linux-9-packaging_and_distributing_software-en-us.pdf, accessed July 3, 2026.</ref>

Practical portability guidance

For old-style Unix/Linux portability, Perl is still one of the best bets after POSIX shell. But modern portability requires checking the target environment.

A portable Perl script should:

• use `#!/usr/bin/env perl` when appropriate;
• document that Perl is required;
• avoid assuming non-core modules are installed;
• avoid assuming a full Perl installation when only `perl-base` exists;
• declare package dependencies in RPM, DEB, APK, ebuild, or other packaging systems;
• use local module installation for application dependencies;
• avoid modifying system Perl with unmanaged CPAN installs;
• test on minimal containers if the script is meant for containers;
• package XS dependencies carefully.

The old assumption was: “Every Unix has Perl.” The modern version is: “Many full Unix-like systems still have Perl, but minimal Linux environments may not.”

Historical importance

Linux helped make Perl universal. During the 1990s and early 2000s, Linux servers, Apache, CGI, Sendmail, system logs, cron jobs, MySQL, and Perl scripts formed a common working environment. Perl was one of the languages that made Linux practical for system administrators and web developers.

Debian made Perl part of its essential system through `perl-base`. Ubuntu and its descendants carried that model to millions of users. Slackware preserved Perl as part of a traditional full Unix-like installation. Fedora, RHEL, and SUSE built serious RPM packaging ecosystems around Perl. Arch and Gentoo showed how Perl behaves under rolling and source-based package management. Alpine and modern container systems showed the limits of old assumptions.

Together, Linux distributions made Perl one of the most widely deployed programming languages in the world. Even when users were not writing Perl directly, Perl was often present underneath package scripts, server tools, web applications, and administrative workflows.

Legacy

Perl’s Linux legacy is the legacy of the system scripting language that was almost always there. It helped administrators automate Linux, helped web developers build early dynamic sites, helped package maintainers write scripts, and helped users solve text-processing problems quickly.

That legacy remains visible, but it has changed. On Debian-family systems and traditional full installations, Perl is still part of the expected environment. On modern enterprise minimal installs, containers, and embedded systems, Perl must often be installed explicitly.

This change does not erase Perl’s Linux importance. It clarifies it. Perl remains one of the great Linux tools, but modern Linux practice treats it less as magic background infrastructure and more as a powerful, mature dependency that should be declared, packaged, and managed intentionally.