Package Managers in a Nutshell

A package manager helps with finding, downloading, installing, configuring, updating, and removing third-party applications in a Unix system. This is not too different when looking at Linux vs. FreeBSD packages.  

A typical invocation starts with the package manager’s name (for example, apt or pkg), followed by a subcommand detailing the action to perform. Package managers typically maintain a local cache of available packages and their current versions, which they periodically synchronize with the package repository.  

This allows the user to find and install new software, perform simple version upgrades of existing packages, and maintain compatibility with operating system libraries and other dependencies for a specific version of the OS. 

Factor #1: FreeBSD’s Single Source vs. Linux’s Diversity

The FreeBSD ports committers create and maintain packages of third-party software published by vendors and make them available to users. The project’s infrastructure provides them with an effortless way of building and distributing the applications via the pkg package manager. A globally distributed mirror network provides the packages for automatic download and installation using the “pkg install” command. 

This makes it easy for FreeBSD users to get started right away, as the 57,000+ software packages available are distributed and updated seamlessly with the operating system. 

Although package management under Linux is generally similar, the package landscape is much more diverse—which is not always a good thing.  Each Linux distro provides its own collection of software in various versions, with varying levels of support provided directly by the distribution. In addition, many distributions (for example, Ubuntu and Arch) offer third-party package repositories—these allow vendors or interested users to make their own packages widely available using the distribution’s tooling, but without much direct support or management by the distro itself.

Many software vendors publish software on their own website for various popular Linux distributions like Ubuntu, Debian, or Red Hat. Although this can increase the total amount of software available, there are several catches to this approach: 

1. Vendors who provide their own direct downloads may refuse to support distribution (re)packaging, while the distro itself refuses to support the vendor’s original code.

2. Software downloaded directly from vendors—even when provided in a distribution’s native package format!—generally do not get automatic upgrades when new versions are present.

3. It can be very confusing for users to figure out what to download and how to install it—vendor-provided software might be in a native package format (like .deb for Ubuntu or Debian), a package format not supported by the user’s distro (like .deb for Red Hat, or .rpm for Ubuntu), or even a source tarball which must be manually built by the user.

In FreeBSD, a port maintainer takes care of making the software work on FreeBSD. A package is built from such a port via a Makefile-based infrastructure, abstracting away all the steps of fetching, configuring, building, and installing the software in the system. 

Most vendors do not provide FreeBSD packages on their website. Instead, they either provide the necessary “pkg install” commands or refer the user to a port when there is no pre-built package available. 

FreeBSD ports typically patch the vendor’s original source code to fit to FreeBSD system libraries, directory layout, necessary dependencies, and other specifics before they can be installed. This greatly simplifies the user experience, since building a port is typically an automated process—in most cases, a simple make install command executed within the port directory is sufficient to download, configure, compile, and install the software itself as well as any necessary dependencies. Although this is still less user-friendly than a pre-built binary package, it’s an enormous improvement compared to manual configuration and compilation!    

Factor #2: Separation Between Base OS Files and Third-party Applications

Another difference when looking at Linux vs. FreeBSD packages is the path of the installed binaries and configuration files. The BSDs have kept a hard-and-fast rule from early on that they distinguish application paths between the ones that the OS provides itself and those coming from third parties. Although Linux theoretically uses the same distinctions, in practice they’re only loosely adhered to!

Take the /etc directory for example. It holds many different configuration files provided by the operating system developers. But where do configuration files for a third-party application end up? 

That is where systems like FreeBSD make a distinction: application configuration files end up under /usr/local/etc, while Linux also puts them in /etc intermingled with the base system’s configuration files. 

This lack of clearly defined boundary between base system and installed applications becomes problematic when external applications overwrite preexisting config files from the operating system. This is often solved by a subdirectory under /etc with the same name of the application. That may sound like a solution—and the BSDs also do create a subdirectory under /usr/local/etc. 

But what happens when it is time to upgrade the base operating system? There may be configuration file changes to be made—and mixing base system configs up with third party application configs increases the potential for confusion and mistakes. 

System backups are one example of where such a lack of boundaries can create problems. On a FreeBSD system, restoring /etc restores the base system configurations, but leaves application configs alone—but on a Linux system, restoring /etc blindly can result in clobbering application configs you had no intent of changing, or leaving “orphaned” config directories with no application—or in badly broken reinstalled apps later, if the package installation routine doesn’t know how to properly handle or recognize a “first time” installation with pre-existing config files.

FreeBSD’s a clear distinction between /usr/local/etc and /etc keeps the OS-specific configuration clean. Backups of /etc do not grow as more applications get installed. The system administrator can always decide to backup only the files belonging to the OS separately from the config files coming from third parties. Upgrades of both the base OS and the applications themselves typically do not have to deal with the maintenance nightmare of intermixed applications. 

Factor #3: Package Availability Between Linux And FreeBSD

New software is usually packaged first for major Linux distributions because of their popularity and large userbase. This is a drawback for FreeBSD, because most software vendors do not include a version for any of the BSDs. Therefore, software must be ported to FreeBSD and that is also where the name “ports” comes from. 

A port committer or maintainer’s first task is often to find ways to “de-Linuxify” software originally developed for a particular Linux environment. Sometimes, this can be as simple as changing paths to prefix /usr/local as the install destination. 

Look at this patch that FreeBSD must apply to the sysutils/neofetch software:

--- neofetch.orig	2022-08-05 13:28:08 UTC
+++ neofetch
@@ -1193,7 +1193,7 @@ get_distro() {
 
     # Get OS architecture.
     case $os in
-        Solaris|AIX|Haiku|IRIX|FreeMiNT)
+        Solaris|AIX|Haiku|IRIX|FreeMiNT|BSD)
             machine_arch=$(uname -p)
         ;;

This patch adds another match to properly detect the BSDs as a valid operating system. 

In other cases, more effort is required—this may include (for example) selecting different dependencies during the build process, changing compiler-time flags and arguments, or modifying how an application interacts with the OS kernel. 

Many such modifications are sent upstream to the originating project for inclusion in future versions. This eases the ongoing maintenance burden for FreeBSD—getting an OS detection IFDEF approved upstream once is much better than repeatedly patching each new release of the software as its upstream developers release it!

Once a software has been initially ported, the resulting upgrade to a higher version is simple in comparison, barring any major rewrite or truckloads of new features. For popular software like Firefox, you will find the latest version to be the same as on other Linux distributions, often appearing on the same day as the software itself.

When there is no port or pkg, there’s a Linuxulator

The “Linuxulator” on FreeBSD is an application binary interface which allows software designed to run under a standard Linux Kernel to work under FreeBSD without direct modification. 

There are instances where porting is too difficult:  for example, proprietary software may be distributed as binary-only, with no access to the source code. Or the complexity or pace of development of a project might be too fast for a FreeBSD port maintainer to keep up with.

This is where the Linuxulator comes in—it runs unmodified packages built on a Linux distro, in much the same way Valve’s well-known “Proton” layer allows most unmodified Windows games to run well under Linux. 

Factor #4 – What’s in the box Package?

Another point to consider in the comparison of Linux vs. FreeBSD packages is the way the packaged software is configured. OS packages bundle certain applications which may have certain options that the user can decide to include or not. When a FreeBSD port is compiled, a menu will let the user select which kind of options should be enabled during compilation and build time, even for any existing dependencies. 

By contrast, packages are pre-built—so it’s “too late” for the user to select their own compile-time options, and these choices are made for the user by the package maintainers.

 For increased compatibility, FreeBSD’s packages are built with conservative options in mind. This may or may not suit everyone’s needs, but it ensures that many systems will run the package and without pulling in too many additional features that not everyone will use. 

LDAP—the Lightweight Directory Access Protocol—is one example of when the difference between ports and packages can be very significant. In a corporate environment, FreeBSD users will have to include LDAP support to connect to their local directories for name lookups and password authentication. 

Since not everyone has an LDAP server in use, the standard package doesn’t include an LDAP dependency—so companies which have LDAP-managed environments must build their own custom packages with the options they need. 

FreeBSD’s own poudriere build-tool allows that and can building (and rebuilding!) custom packages, even when newer versions are released. To distribute those packages within the corporate network, a new package source created by poudriere is entered into /etc/pkg/ in order to prioritize the locally-built version over the one found in FreeBSD’s own repositories.

Linux also provides tools to build packages when necessary. This is needed when a library is missing or does not have the required version. Especially when older software is downloaded from a vendor on a newer distribution version, it may be that the bundled dependencies do not work anymore. 

The author has been to more than one application training course where to the actual training couldn’t begin until resolution of dependency installation issues for various Linux distributions was thoroughly covered. 

In recent years, many Linux distributions have taken great care to avoid that by providing LTS (long-term support) versions of their software. That way, users can stay with one operating system version longer, while the applications running on it are still receiving updates until the OS version’s end of life.

Factor #5 – Update Frequency

FreeBSD pkg users can decide between bleeding-edge packages with the latest branch, or a slower update pace with the quarterly branch. Each approach has both pros and cons. Both quarterly and latest package branches receive security updates. Quarterly packages are intended for longer-term, stable usage where chasing the newest software versions is not desired. The “latest” branch, by contrast, is intended for users who always want the latest versions of their applications with the most recent features.

On various Linux distributions, both packages and the distribution itself may be divided into categories such as stable, main, unstable, testing, and so forth. The exact list and type of category is different for each Linux distribution.

This complexity and lack of standardization can be confusing for newcomers, and may even seem less trustworthy. After all, who wants to run unstable software? Some Linux distributions even allow mixing these categories, with “stable”, and “unstable” packages installed side by side.

On FreeBSD, the user can only run one of the two. If the system uses quarterly packages (installation default) and switches to the latest branch, packages get updated when there are newer versions available. On the other hand, switching from latest to quarterly may result in some packages being downgraded as only the older versions are in those branches. 

However, the FreeBSD package system takes care of not mixing up quarterly and latest. This improves the stability of the system, avoiding an entire class of debugging problems which may arise if incompatible software versions are intermixed.

Conclusion

Although Linux has a greater amount of software available from both commercial and open source vendors, FreeBSD’s package availability continues to rise steadily.— In environments where custom packages with non-standardcompile time options are necessary, FreeBSD’s excellent ports system and poudriere automated build system can also be as or more important than the number of pre-built packages in a system repository.

FreeBSD’s quarterly and latest package branches offer a simple and straightforward experience for both bleeding-edge users and those wanting to have an easier update pace. 

Finally, FreeBSD’s clear distinction between base system and package installation paths under /usr/local ensures stability as an OS upgrade will not be affected by intermixed third-party software.