Editing 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:

<pre>
pkg install perl5
</pre>

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:

<pre>
#!/usr/bin/env perl
</pre>

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:

<pre>
USES=        perl5
USE_PERL5=   build
</pre>

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

<pre>
USES=        perl5
USE_PERL5=   configure
</pre>

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.