Portal:FreeBSD,OpenBSD,etc

FreeBSD and Perl

FreeBSD has had a long and complicated relationship with Perl. In the 1990s, Perl was close to the Unix system-administration culture from which FreeBSD also grew. Perl was useful for build tools, package tools, administrative scripts, text processing, reporting, mail processing, ports maintenance, and the daily work of Unix developers and system administrators.

FreeBSD eventually made an important design decision: Perl should remain available and well supported, but it should not be part of the base operating system. This choice shaped FreeBSD’s later identity. FreeBSD kept a small, carefully maintained base system, while Perl moved into the Ports Collection and binary package system, where it could be upgraded and managed like other third-party software.

Perl in the early FreeBSD base system

Early FreeBSD systems included Perl as part of the base operating system. This was normal for many Unix-like systems of the period. Perl was widely used for scripts, installation tools, package tools, and administration. It was also expected by many users coming from Unix and early Internet-server environments.

By FreeBSD 3.0, Perl 5 had replaced Perl 4 as a standard part of the system. The FreeBSD 3.0 release notes state: “Perl4 has now been replaced by Perl5 as a standard part of the system.”<ref>FreeBSD Project, “FreeBSD 3.0 Release Notes,” https://www.freebsd.org/releases/3.0R/notes/, accessed July 3, 2026.</ref>

This was historically important because Perl 5 was a much more capable language than Perl 4. Perl 5 brought references, modules, lexical variables, object-oriented programming support, and a modern CPAN ecosystem. For FreeBSD users and developers, having Perl 5 in the base system meant that Perl scripts could be assumed to exist on a standard FreeBSD installation.

That convenience also created a problem. Once Perl was part of the base system, parts of FreeBSD could start depending on it. Upgrading Perl then became tied to upgrading the operating system itself.

The decision to remove Perl from base

In 2002, the FreeBSD project announced that Perl 5 would be removed from the base system for FreeBSD 5.0 and later. The announcement stated that the decision had been made after debate and in consultation with the Perl 5 developer community.<ref>Mark Murray, “Perl5 is leaving the base system for 5.0 and after!,” freebsd-announce, May 15, 2002, https://lists.freebsd.org/pipermail/freebsd-announce/2002-May/000823.html, accessed July 3, 2026.</ref>

The announcement gave two main reasons. First, Perl 5 was becoming larger, and FreeBSD did not want to carry the time and space cost of building and maintaining it as part of the base system. Second, upgrading the “base Perl” regularly broke upgrades and cross-builds, creating serious maintenance problems for FreeBSD developers.<ref>Mark Murray, “Perl5 is leaving the base system for 5.0 and after!,” freebsd-announce, May 15, 2002, https://lists.freebsd.org/pipermail/freebsd-announce/2002-May/000823.html, accessed July 3, 2026.</ref>

The announcement also emphasized that this was not an anti-Perl decision. It explicitly said: “PERL IS NOT BEING OSTRACISED!” and “FreeBSD DOES NOT HATE PERL!”<ref>Mark Murray, “Perl5 is leaving the base system for 5.0 and after!,” freebsd-announce, May 15, 2002, https://lists.freebsd.org/pipermail/freebsd-announce/2002-May/000823.html, accessed July 3, 2026.</ref>

This distinction matters. FreeBSD did not remove Perl because Perl was useless. It removed Perl because the FreeBSD base system needed to be self-contained, easier to cross-build, easier to upgrade, and less dependent on a large third-party language runtime.

FreeBSD 5.0 and the post-base Perl model

FreeBSD 5.0 formalized the change. The FreeBSD 5.0 release notes state that Perl had been removed from the FreeBSD base system and could be installed from the Ports Collection, as a binary package, or through the Perl distribution item in sysinstall.<ref>FreeBSD Project, “FreeBSD 5.0-RELEASE Release Notes,” https://www.freebsd.org/releases/5.0R/relnotes-alpha/, accessed July 3, 2026.</ref>

The release notes also explain the purpose of the change: moving Perl out of the base system would make future upgrades and maintenance easier. To reduce the base system’s dependence on Perl, many utilities were rewritten as shell scripts or C programs.<ref>FreeBSD Project, “FreeBSD 5.0-RELEASE Release Notes,” https://www.freebsd.org/releases/5.0R/relnotes-alpha/, accessed July 3, 2026.</ref>

The same release notes mention two historically significant details. First, Perl script removal work was still ongoing. Second, most distribution sets included the new Perl distribution, so the change would be transparent to many users, except that Perl would now be upgraded separately from the base system.<ref>FreeBSD Project, “FreeBSD 5.0-RELEASE Release Notes,” https://www.freebsd.org/releases/5.0R/relnotes-alpha/, accessed July 3, 2026.</ref>

This created the modern FreeBSD model: the base operating system does not depend on Perl, but Perl remains readily available as an add-on package or port.

Base system philosophy

The Perl removal reflected FreeBSD’s larger distinction between the base system and third-party software.

The FreeBSD base system includes the kernel, core userland, libraries, build system, startup scripts, manual pages, and core administrative tools maintained together by the FreeBSD project. Third-party software is handled through the Ports Collection and binary packages.

This separation is one of FreeBSD’s defining features. It differs from many Linux distributions, where the operating system is assembled almost entirely from packages managed by the distribution package manager. In FreeBSD, the base system and packages are historically separate layers.

Perl’s move out of base therefore made a philosophical point: even an extremely useful language should not necessarily be part of the operating system core if it complicates base maintenance and cross-building.

Perl in packages and ports today

Today Perl is installed on FreeBSD through the package system or the Ports Collection. A user can install Perl with:

pkg install perl5

The current Perl port installs into `/usr/local`, not into the base-system directories. FreshPorts lists `lang/perl5.42` as Perl 5.42.2, maintained by [mat@FreeBSD.org](mailto:mat@FreeBSD.org), licensed under the Artistic License 1.0 and GPLv1+, and listed in both the `lang` and `perl5` categories.<ref>FreshPorts, “lang/perl5.42: Practical Extraction and Report Language,” https://www.freshports.org/lang/perl5.42/, accessed July 3, 2026.</ref>

The installed files include `/usr/local/bin/perl`, versioned Perl binaries such as `/usr/local/bin/perl5.42.2`, and standard Perl tools such as `cpan`, `corelist`, `perldoc`, `prove`, `pod2man`, `pod2text`, `xsubpp`, and others.<ref>FreshPorts, “lang/perl5.42: Practical Extraction and Report Language,” https://www.freshports.org/lang/perl5.42/, accessed July 3, 2026.</ref>

This is important for portability. On modern FreeBSD, scripts should not assume that `/usr/bin/perl` exists. The normal package-installed Perl lives under `/usr/local/bin/perl`. Portable scripts often use:

#!/usr/bin/env perl

or are patched by the ports framework to use the correct interpreter path.

The perl5 category and p5-* ports

FreeBSD has a dedicated `perl5` virtual category in the Ports Collection. The FreeBSD Porter's Handbook describes the `perl5` category as “Ports that require Perl version 5 to run.”<ref>FreeBSD Project, “FreeBSD Porter's Handbook,” https://docs.freebsd.org/en/books/porters-handbook/book/, accessed July 3, 2026.</ref>

Perl module ports are commonly named with the `p5-` prefix. For example, a CPAN module such as `DBI` would normally appear as a FreeBSD port named something like `p5-DBI`. This naming convention makes Perl modules easy to find and distinguishes Perl module packages from applications written in Perl or from non-Perl libraries.

This approach gives FreeBSD a bridge between CPAN and the FreeBSD package system. A Perl user can install modules directly from CPAN, but a system administrator often prefers FreeBSD packages because they are tracked by `pkg`, upgraded through normal package workflows, and built against the FreeBSD ports framework.

USES=perl5 and USE_PERL5

For port maintainers, Perl support is handled through the ports framework. The Porter's Handbook says that when a port needs Perl support, it must set `USES=perl5`, with optional behavior controlled by `USE_PERL5`.<ref>FreeBSD Project, “FreeBSD Porter's Handbook,” https://docs.freebsd.org/en/books/porters-handbook/book/, accessed July 3, 2026.</ref>

The handbook documents variables made available to Perl-using ports, including `PERL`, `PERL_VERSION`, `PERL_LEVEL`, `PERL_ARCH`, `PERL_PORT`, and `SITE_PERL`.<ref>FreeBSD Project, “FreeBSD Porter's Handbook,” https://docs.freebsd.org/en/books/porters-handbook/book/, accessed July 3, 2026.</ref>

`USE_PERL5` can specify the phases in which Perl is needed, such as `extract`, `patch`, `build`, `run`, or `test`. It can also specify Perl build systems such as `configure` for `Makefile.PL`, `modbuild` for `Build.PL`, or `modbuildtiny` for `Module::Build::Tiny`.<ref>FreeBSD Project, “FreeBSD Porter's Handbook,” https://docs.freebsd.org/en/books/porters-handbook/book/, accessed July 3, 2026.</ref>

For example, a port that needs Perl only to build can use:

USES=        perl5
USE_PERL5=   build

A typical CPAN-style module that uses `Makefile.PL` can use:

USES=        perl5
USE_PERL5=   configure

This ports-framework support is one reason Perl remains well integrated into FreeBSD even though it is no longer part of the base system.

Default Perl versions

FreeBSD’s ports tree maintains a default Perl version. That default can change over time, and Perl upgrades can require rebuilding dependent ports, especially when compiled modules depend on a specific `libperl` shared library.

The ports `UPDATING` file records major Perl default-version changes. For example, the 2025-08-17 entry states that the default Perl version was switched to 5.42 and points users to earlier updating instructions.<ref>FreeBSD Ports, “UPDATING,” https://github.com/freebsd/freebsd-ports/blob/main/UPDATING, accessed July 3, 2026.</ref>

This matters because FreeBSD packages are built as a coherent set. Users who install binary packages normally let `pkg upgrade` handle version transitions. Users who build from ports may need to follow `UPDATING`, set `DEFAULT_VERSIONS` temporarily, rebuild Perl, and rebuild dependent packages.

The key point is that Perl is managed as part of the ports ecosystem, not as a fixed operating-system component.

BSDPAN and CPAN integration

FreeBSD 5.0 also introduced BSDPAN, described in the release notes as a collection of modules that provided tighter integration of Perl into the FreeBSD Ports Collection.<ref>FreeBSD Project, “FreeBSD 5.0-RELEASE Release Notes,” https://www.freebsd.org/releases/5.0R/relnotes-alpha/, accessed July 3, 2026.</ref>

BSDPAN was historically important because it addressed a common problem: CPAN has its own module-installation system, while FreeBSD has its own package database. If a user installs modules through CPAN, the FreeBSD package manager may not fully know what was installed. FreeBSD’s Perl integration work tried to reduce the friction between CPAN-style Perl use and ports/pkg-style system administration.

In practice, FreeBSD administrators often prefer installing Perl modules from `p5-*` packages when possible, especially on production systems. CPAN remains useful for development, testing, or modules not available in ports, but packages are easier to audit, upgrade, and remove using FreeBSD’s normal tools.

Perl and FreeBSD development infrastructure

Perl’s removal from the base system did not mean that Perl disappeared from FreeBSD development infrastructure. It changed where Perl was allowed to matter.

The FreeBSD source tree is expected to build without requiring Perl in the base system. That is the practical consequence of the 5.0-era decision. Tools that are required to build and install the core system should not assume a base Perl interpreter.

However, FreeBSD’s wider development infrastructure still includes Perl in several places:

• Perl is heavily represented in the Ports Collection through `p5-*` module ports and Perl-using applications.
• The ports framework contains explicit support for Perl through `USES=perl5` and `USE_PERL5`.
• Developer and maintainer tools may use Perl when they are installed from ports or run in environments where Perl is available.
• FreeBSD’s bug-tracking infrastructure is based on Bugzilla, which is historically a Perl application.

FreeBSD’s Bugzilla customizations are especially notable. The `freebsd/bugzilla` repository describes itself as a set of changes and extensions for Bugzilla used by the FreeBSD project. Its repository listing shows project-specific Perl scripts such as `monthlyexprun.pl`, `sync_freebsd_committers.pl`, and `weeklyreminder.pl`, and GitHub’s language summary lists the repository as mostly Perl.<ref>FreeBSD, “freebsd/bugzilla,” https://github.com/freebsd/bugzilla, accessed July 3, 2026.</ref>

Bugzilla itself has a Perl history. The Bugzilla project says that Bugzilla was originally written in Tcl, but Terry Weissman ported it to Perl in 1998 because Perl seemed more popular and likely to attract contributors.<ref>Bugzilla Project, “About Bugzilla,” https://www.bugzilla.org/about/, accessed July 3, 2026.</ref>

This means Perl remains part of the FreeBSD project’s broader ecosystem even though the operating system base was intentionally made Perl-independent.

Git, ports, and modern development workflow

FreeBSD development now uses Git for the source, documentation, and ports repositories. The FreeBSD Foundation’s guide to updating FreeBSD from Git says that FreeBSD’s migration from Subversion to Git changed how users get source, update trees, and bisect changes. It lists `git.FreeBSD.org` as the public source repository location and describes `main` as the development branch for FreeBSD-CURRENT.<ref>FreeBSD Foundation, “Updating FreeBSD From Git,” https://freebsdfoundation.org/resource/updating-freebsd-from-git/, accessed July 3, 2026.</ref>

The same guide describes the documentation and ports repositories as Git repositories as well, with the ports tree using `main` for latest development and quarterly branches for package branches.<ref>FreeBSD Foundation, “Updating FreeBSD From Git,” https://freebsdfoundation.org/resource/updating-freebsd-from-git/, accessed July 3, 2026.</ref>

In this modern workflow, Perl’s role is mostly in ports, packages, scripts, and web infrastructure rather than in the base operating system. A developer working on the kernel or base userland should not need Perl merely to build the system. A ports developer, however, may encounter Perl constantly through CPAN-derived ports, Perl build dependencies, module packaging, and ports infrastructure variables.

FreeBSD compared with other BSDs

FreeBSD’s decision to remove Perl from base distinguishes it from some other BSD systems. OpenBSD, for example, has historically kept Perl in base because some base tools depend on it. FreeBSD chose the opposite path: reduce the base system’s dependency on Perl and make Perl a managed third-party component.

This difference reflects different project priorities. FreeBSD emphasized base-system maintainability, cross-build reliability, and separation between the operating system and packages. Perl remained available, but FreeBSD no longer treated it as a guaranteed base-system interpreter.

That choice has advantages and disadvantages. The advantage is a cleaner, more self-contained base. The disadvantage is that third-party Perl scripts written for older Unix assumptions may fail if they expect `/usr/bin/perl`.

Practical consequences for users

For FreeBSD users, the practical consequences are straightforward:

• Install Perl with `pkg install perl5` or from `lang/perl5.*` in the Ports Collection.
• Use `p5-*` packages for CPAN modules when possible.
• Avoid assuming `/usr/bin/perl`; use `/usr/local/bin/perl` or `/usr/bin/env perl`.
• Follow `/usr/ports/UPDATING` when building from ports and the default Perl version changes.
• Prefer package-managed Perl modules on production systems when auditability and clean upgrades matter.
• Use CPAN carefully when a module is not available as a FreeBSD port.

This makes Perl on FreeBSD less “invisible” than on systems where Perl is always in base, but more explicit and maintainable.

Historical importance

FreeBSD’s Perl history is important because it shows both Perl’s usefulness and the cost of depending on a large scripting language inside an operating-system base.

In the early FreeBSD era, Perl was valuable enough to be included as part of the system. By FreeBSD 3.0, Perl 5 had replaced Perl 4 in base. But by FreeBSD 5.0, the project decided that Perl’s size, upgrade complexity, and cross-build complications outweighed the convenience of keeping it in base.

The result was not a rejection of Perl. It was a relocation of Perl. Perl moved from being part of the base operating system to being a first-class package and port. That made Perl easier to upgrade independently and made the FreeBSD base system easier to maintain.

Legacy

Perl’s FreeBSD legacy is one of practical Unix usefulness balanced against operating-system discipline. Perl was useful enough to be part of early FreeBSD, powerful enough to shape administrative and development workflows, and important enough to receive dedicated ports-framework support after removal from base.

Today Perl remains deeply available on FreeBSD through packages and ports. The `perl5` category, `p5-*` module naming convention, `USES=perl5`, `USE_PERL5`, and FreeBSD’s Perl-aware ports infrastructure all show that Perl is still supported seriously.

At the same time, the base system no longer assumes Perl. That is the central lesson of FreeBSD’s Perl history: Perl remains a powerful tool for FreeBSD users and developers, but FreeBSD deliberately keeps the core operating system independent from it.

OpenBSD, NetBSD, DragonFly BSD, and Perl

The BSD family provides an unusually interesting comparison of operating-system philosophy through the treatment of Perl. FreeBSD removed Perl from its base system in the FreeBSD 5.0 era and moved it fully into ports/packages. OpenBSD took the opposite approach and continues to ship Perl in the base operating system. NetBSD’s story is centered on pkgsrc, its portable package system. DragonFly BSD inherited much of the FreeBSD ports model through DPorts.

Together, these systems show the major ways a Unix-like operating system can relate to Perl: as a base-system language, as a package-managed third-party language, as a ports-framework dependency, and as development infrastructure.

OpenBSD: Perl in the base system

OpenBSD is the major modern BSD that most clearly continues the older Unix tradition of shipping Perl as part of the base system. OpenBSD 7.8, released October 22, 2025, lists Perl 5.40.1 (+ patches) among the major outside components included in the system.<ref>OpenBSD Project, “OpenBSD 7.8,” https://www.openbsd.org/78.html, accessed July 3, 2026.</ref>

This is a sharp contrast with FreeBSD. FreeBSD decided that Perl should be managed outside the base system. OpenBSD continues to treat Perl as useful enough, stable enough, and integrated enough to remain part of the default operating system.

The OpenBSD manual page set includes `perl(1)` and the normal Perl documentation pages, and OpenBSD also has a `perlopenbsd(1)` page describing Perl version 5 on OpenBSD systems.<ref>OpenBSD Project, “perl(1),” https://man.openbsd.org/perl.1, accessed July 3, 2026.</ref><ref>Perl Documentation, “perlopenbsd - Perl version 5 on OpenBSD systems,” https://perldoc.perl.org/perlopenbsd, accessed July 3, 2026.</ref>

OpenBSD’s decision to keep Perl in base is not merely sentimental. Some OpenBSD infrastructure is written in Perl or has historically depended on Perl. Most notably, OpenBSD’s package tools and package-library code have a strong Perl history.

OpenBSD package tools and Perl

OpenBSD’s package manager, including `pkg_add`, is central to the system’s Perl story. The `pkg_add(1)` manual page describes `pkg_add` as the command used to install or update packages created from the ports tree.<ref>OpenBSD Project, “pkg_add(1),” https://man.openbsd.org/pkg_add, accessed July 3, 2026.</ref>

OpenBSD also documents Perl package-infrastructure modules under the `OpenBSD::` namespace. For example, `OpenBSD::Intro(3p)` describes package-system concepts such as dependencies, conflicts, and replacement behavior, while `OpenBSD::PackingList(3p)` documents Perl handling of package packing lists.<ref>OpenBSD Project, “OpenBSD::Intro(3p),” https://man.openbsd.org/OpenBSD%3A%3AIntro.3p, accessed July 3, 2026.</ref><ref>OpenBSD Project, “OpenBSD::PackingList(3p),” https://man.openbsd.org/OpenBSD%3A%3APackingList.3p, accessed July 3, 2026.</ref>

Marc Espie’s 2010 EuroBSDCon presentation “The long long road to pkg_add -u” explains the historical design choice. It describes the earlier package tools as C-based, slow, and a “hack,” then identifies the “most controversial decision” in the newer package-tool design as Perl. The presentation gives practical reasons for Perl: the need for a rapid application-development platform, Perl’s modularity and namespace system, and the fact that Perl was already part of the OpenBSD base system.<ref>Marc Espie, “The long long road to pkg_add -u,” EuroBSDCon 2010, https://2010.eurobsdcon.org/fileadmin/fe_user/espie/CBzd55.pdf, accessed July 3, 2026.</ref>

This makes OpenBSD unusual among modern operating systems. Perl is not only a scripting language available to users; it is part of the design history of the package system itself.

OpenBSD ports and Perl modules

OpenBSD also supports Perl modules through its ports tree. Perl module packages normally appear with the `p5-` prefix, as in other BSD package systems. OpenBSD’s `portgen(1)` utility can generate ports for module ecosystems, and its documentation says that the `p5` type is used for Perl modules on CPAN.<ref>OpenBSD Project, “portgen(1),” https://man.openbsd.org/OpenBSD-current/man1/portgen.1, accessed July 3, 2026.</ref>

The OpenBSD ports framework also has explicit Perl support. The `port-modules(5)` manual page says that the OpenBSD ports framework is based on `bsd.port.mk`, and that optional port modules exist for mechanisms such as GNU autoconf and `perl5`. It further notes that setting `CONFIGURE_STYLE` can be enough to get `perl5` support, although `perl5` is actually a ports module.<ref>OpenBSD Project, “port-modules(5),” https://man.openbsd.org/port-modules, accessed July 3, 2026.</ref>

This means OpenBSD uses Perl in two layers:

• Perl is part of the base system.
• Additional Perl modules are managed through ports and packages.

That split is important. The base Perl is part of the operating system and is maintained with OpenBSD. CPAN modules and third-party Perl applications belong in the ports/packages layer.

OpenBSD development process and Perl

OpenBSD’s Perl work follows the larger OpenBSD development model. OpenBSD is developed primarily through CVS, with public read-only Git mirrors. The OpenBSD source mirror on GitHub describes itself as a read-only conversion of the official CVS source repository and explicitly says that pull requests are not accepted; diffs should be sent to the `tech@` mailing list.<ref>OpenBSD Project, “openbsd/src,” GitHub mirror, https://github.com/openbsd/src, accessed July 3, 2026.</ref>

That applies to Perl-related base-system work as well. Perl in OpenBSD is not upgraded by a user running CPAN over the system interpreter. It is imported, patched, tested, and committed as part of the OpenBSD source tree.

OpenBSD release notes also describe Perl as an outside component with local patches, showing the project’s normal approach to imported software: take an upstream component, patch it for OpenBSD’s needs, and maintain it as part of the system release.<ref>OpenBSD Project, “OpenBSD 7.8,” https://www.openbsd.org/78.html, accessed July 3, 2026.</ref>

The OpenBSD package-tool maintainers continue to discuss Perl actively. In a 2023 message summarized by OpenBSD Journal, Marc Espie wrote about the future of `pkg_*`, testing, regression infrastructure, and converting package-tool code to Perl 5.36, specifically mentioning that signatures made the Perl code more readable and easier for new people to enter.<ref>OpenBSD Journal, “pkg_*: the road forward,” https://undeadly.org/cgi?action=article;sid=20230712135010, accessed July 3, 2026.</ref>

This illustrates the OpenBSD attitude toward Perl: conservative, integrated, pragmatic, and focused on maintainability. Perl is kept because it solves problems inside the system.

OpenBSD and security culture

OpenBSD is known for security-focused engineering, code review, correctness, and a small, coherent base system. At first glance, keeping Perl in base may seem inconsistent with minimalism. But OpenBSD’s position is more practical than minimalist absolutism.

Perl is already there, it is stable, its backward compatibility is strong, and important OpenBSD tooling uses it. Removing it would require rewriting working infrastructure, especially package tools and related scripts. OpenBSD therefore treats Perl as part of the trusted base rather than as an optional convenience.

OpenBSD 7.8 also shows that the project is willing to replace Perl tools when there is a practical reason. The release notes say that `pkg-config(1)` was switched to the C-based `pkgconf` because of major performance issues with an unmaintained homegrown Perl script.<ref>OpenBSD Project, “OpenBSD 7.8,” https://www.openbsd.org/78.html, accessed July 3, 2026.</ref>

This is a useful nuance. OpenBSD does not keep every Perl script forever. It keeps Perl where Perl remains useful, but it can replace Perl code when performance, maintenance, or correctness argues for a different implementation.

NetBSD and pkgsrc

NetBSD has a different Perl story. NetBSD is strongly associated with portability, and its package system, pkgsrc, became one of the most portable package systems in the Unix world.

pkgsrc describes itself as a framework for managing third-party software on Unix-like systems, containing more than 26,000 packages. It is the default package manager of NetBSD and SmartOS and can also be used on many other Unix-like systems. The pkgsrc site notes that NetBSD already contains the necessary tools for using pkgsrc, while other platforms need to bootstrap pkgsrc first.<ref>pkgsrc, “The pkgsrc package management system,” https://www.pkgsrc.org/, accessed July 3, 2026.</ref>

Perl is available in pkgsrc as `lang/perl5`. The current pkgsrc page describes Perl as a general-purpose programming language originally developed for text manipulation and lists the current source version as `perl-5.42.2nb3`.<ref>NetBSD Packages Collection, “lang/perl5,” https://cdn.netbsd.org/pub/pkgsrc/current/pkgsrc/lang/perl5/index.html, accessed July 3, 2026.</ref>

pkgsrc also contains many Perl module packages, traditionally named with a `p5-` prefix. For example, `devel/p5-Module-Runtime` and `devel/p5-IPC-Run` are typical pkgsrc Perl-module packages.<ref>NetBSD Packages Collection, “devel/p5-Module-Runtime,” https://ftp.netbsd.org/pub/NetBSD/NetBSD-current/pkgsrc/devel/p5-Module-Runtime/index.html, accessed July 3, 2026.</ref><ref>NetBSD Packages Collection, “devel/p5-IPC-Run,” https://ftp.netbsd.org/pub/pkgsrc/current/pkgsrc/devel/p5-IPC-Run/index.html, accessed July 3, 2026.</ref>

NetBSD’s Perl story is therefore less about Perl being a base-system scripting language and more about Perl as a first-class pkgsrc citizen. Perl and CPAN modules are packaged, built across architectures, and made available through the same framework that supports thousands of other packages.

pkgsrc as a Perl preservation layer

pkgsrc is historically important for Perl because it makes Perl portable beyond one operating system. Although pkgsrc began in the NetBSD world, it runs on many platforms. That means Perl modules packaged in pkgsrc can benefit users on NetBSD, SmartOS, illumos, macOS, Linux, and other systems supported by pkgsrc.

This is a different philosophy from OpenBSD. OpenBSD keeps Perl in base because it is part of the operating system’s own infrastructure. NetBSD/pkgsrc makes Perl portable by treating it as a package and by maintaining thousands of Perl modules through a cross-platform package framework.

For Perl users, pkgsrc is valuable because it provides a system package manager’s view of Perl modules. Instead of installing everything directly from CPAN, administrators can install `p5-*` packages that are tracked, upgraded, and removed through pkgsrc tools.

DragonFly BSD and DPorts

DragonFly BSD was forked from FreeBSD 4.8 and developed its own kernel and system architecture, especially around SMP, clustering ideas, and the HAMMER/HAMMER2 filesystems. Its third-party software model is based on DPorts.

DragonFly’s documentation says that DPorts is DragonFly’s own third-party software build system and that it is based on FreeBSD’s Ports Collection. The documentation adds that differences between FreeBSD ports and DPorts are intentionally kept to a minimum, both for familiarity and to leverage FreeBSD ports work.<ref>DragonFly BSD, “DPorts and pkg(8),” https://www.dragonflybsd.org/docs/howtos/DPortsUsage/, accessed July 3, 2026.</ref>

The same page says that DragonFly daily snapshots and releases starting with DragonFly 3.4 come with `pkg(8)` already installed, and that `pkg` is used as the binary package manager.<ref>DragonFly BSD, “DPorts and pkg(8),” https://www.dragonflybsd.org/docs/howtos/DPortsUsage/, accessed July 3, 2026.</ref>

The DragonFly DPorts repository describes DPorts as a derivative of FreeBSD’s Ports Collection. It says DPorts serves the same purpose for DragonFly that the Ports Collection serves for FreeBSD, and that products of DPorts are executable software manipulated by the `pkg(8)` binary package manager.<ref>DragonFly BSD, “DragonFlyBSD/DPorts,” GitHub, https://github.com/dragonflybsd/dports, accessed July 3, 2026.</ref>

Perl on DragonFly therefore follows the FreeBSD-like model more than the OpenBSD model. Perl is primarily a package/ports-managed language. Perl module packages follow the ports tradition, and Perl version changes are handled as part of the DPorts/pkg ecosystem rather than as a base-system language contract.

DragonFly DPorts development process

DragonFly’s DPorts development process is interesting because it is explicitly derivative and automated. DragonFly documentation says the DPorts workflow uses three repositories: FreeBSD Ports, DeltaPorts, and DPorts. DeltaPorts is an overlay applied on top of FreeBSD Ports to create DPorts.<ref>DragonFly BSD, “DPorts Contributions,” https://www.dragonflybsd.org/docs/howtos/DPortsContributions/, accessed July 3, 2026.</ref>

The same documentation describes monthly syncs with FreeBSD Ports, transformation scripts, staged builds, build-status tracking, and failure-fixing. It also explains that users can help by testing ports, reporting bugs, checking pull requests, and fixing DPorts failures.<ref>DragonFly BSD, “DPorts Contributions,” https://www.dragonflybsd.org/docs/howtos/DPortsContributions/, accessed July 3, 2026.</ref>

For Perl, this means DragonFly benefits from FreeBSD’s Perl ports work but must still account for DragonFly-specific build and runtime differences. Perl itself and Perl modules come through the package system, but the DPorts layer may need local fixes when FreeBSD ports do not build cleanly on DragonFly.

MidnightBSD, GhostBSD, HardenedBSD, and desktop BSD derivatives

Other BSD-family systems usually inherit their Perl approach from the system they are based on.

GhostBSD is a desktop-oriented system based on FreeBSD. Its Perl story generally follows FreeBSD: Perl and Perl modules are installed through packages rather than treated as part of the core base system.

HardenedBSD is also FreeBSD-derived. It focuses on security hardening, exploit mitigations, and related work. Its Perl handling likewise follows the FreeBSD ports/packages model, although package availability and build choices may vary depending on the HardenedBSD package repository and branch.

MidnightBSD was also originally derived from FreeBSD. It has its own ports-derived package system, but its Perl relationship is still broadly FreeBSD-like: Perl is managed as third-party software rather than as an OpenBSD-style base-system language.

These systems are historically interesting because they show FreeBSD’s influence. Once FreeBSD moved Perl out of base and into packages, FreeBSD-derived systems usually inherited that model.

macOS, Darwin, and BSD userland influence

macOS and Darwin are not BSD distributions in the same sense as FreeBSD, OpenBSD, NetBSD, or DragonFly, but they are BSD-derived in important userland and networking areas. Historically, macOS shipped Perl as part of the developer and Unix scripting environment, and Perl was used by administrators, packaging tools, and Unix-oriented workflows on macOS.

Modern macOS has moved away from encouraging reliance on Apple-provided scripting-language runtimes. Apple has deprecated or reduced emphasis on bundled scripting runtimes in favor of users installing their own current versions through systems such as Homebrew, MacPorts, pkgsrc, or language-specific installers.

In a BSD-history article, macOS is worth mentioning because it shows the same general trend as FreeBSD from a different direction: a vendor-provided Perl may exist for compatibility, but serious Perl development is usually better served by a package manager or user-installed Perl.

Comparing the BSD approaches

The BSD systems show several different models for Perl:

• OpenBSD keeps Perl in the base system and uses it in important operating-system infrastructure, especially package tools.
• FreeBSD removed Perl from the base system and manages it through ports and packages.
• NetBSD emphasizes pkgsrc, where Perl and Perl modules are package-managed and portable across many Unix-like systems.
• DragonFly BSD uses DPorts, a FreeBSD-ports-derived system, with Perl handled through packages.
• FreeBSD-derived desktop and security BSDs generally inherit the FreeBSD package-managed Perl model.
• macOS/Darwin historically shipped Perl but increasingly encourages separately managed language runtimes for serious development.

This comparison is useful because it shows that “BSD and Perl” is not one story. Each BSD made a different tradeoff between base-system convenience, package-system flexibility, portability, and maintenance burden.

Historical importance

The BSD family is important to Perl history because BSD systems are close to Perl’s Unix roots. Perl grew up in the same culture of text files, shell scripts, system administration, mail tools, source trees, ports, manual pages, and practical automation.

OpenBSD demonstrates the strongest continuing base-system commitment to Perl. FreeBSD demonstrates the consequences of moving Perl out of base. NetBSD demonstrates Perl’s package portability through pkgsrc. DragonFly demonstrates how Perl follows a ports-derived ecosystem in a smaller BSD.

These systems also show that Perl’s value is not only in web applications or CPAN modules. Perl has been useful inside operating-system infrastructure itself: package tools, port-generation tools, build scripts, regression tools, documentation helpers, and administration utilities.

Legacy

Perl’s BSD legacy is one of deep Unix integration. On OpenBSD, Perl remains a standard part of the operating system and a living part of package-management infrastructure. On FreeBSD and DragonFly, Perl is managed through ports and packages. On NetBSD, Perl is part of the broader pkgsrc portability story.

The differences are instructive. OpenBSD proves that a modern security-focused operating system can still choose to ship Perl in base when it serves the system’s needs. FreeBSD proves that removing Perl from base can simplify the core operating system while preserving Perl through packages. NetBSD proves that Perl can be supported across many architectures and operating systems through a portable package framework. DragonFly proves that Perl can ride along with a FreeBSD-derived ports ecosystem while adapting to a different BSD kernel and userland.

Together, the BSDs show Perl’s durability. Whether in base or in packages, Perl remains part of the Unix and BSD landscape because it is useful, portable, mature, and well suited to the practical work of operating systems.