Support for *BSD

[kraileth]

In an issue here it was proposed to add support for the BSD family of operating systems and @furlongm asked a couple of questions #457 (comment) there.

Historically the earliest means of package management in Open Source was Jordan Hubbard's introduction of what is known as the FreeBSD Ports Collection. It shipped with the first incarnation of the pkg_* tools (not too much later the Bogus Linux distribution was released with the PMS package manager that would more or less evolve into RPM). Both the ports tree concept and the package management tools spread to all the other BSD systems.

While they do have common ancestry they have diverged a lot. OpenBSD's ports tree works very differently from FreeBSD's. NetBSD's, which goes by the name Pkgsrc, is even portable across platforms (you can use it on multiple BSDs, on Linux, Solaris but also AIX, HP-UX and more). About 10 years ago FreeBSD replaced the aging pkg_* tools with a new tool called pkg(8) (anybody familiar with apt or yum will get along with it quickly). DragonFly BSD also adopted pkg(8) but the other BSDs stuck with pkg_* - which does not mean that they are compatible! At some point OpenBSD did a complete re-write in Perl. NetBSD's are still closest to the original tools but they supplemented it with the pkgin(1) frontend which is unique.

You can still build software from ports, but this is not very common anymore. FreeBSD recommends not to do it directly (people who need customized build options set are meant to use a ports builder application to roll their own package set). OpenBSD strongly recommends not to build from ports. But even if you do, the resulting software installation gets recorded in the package database. So from patchman's perspective you can completely ignore that there's such a thing as a ports tree: Just query the package manager about software installed on the system and it will happily tell you no matter if it was installed from pre-built packages or built from ports.

All the BSDs are also different from Linux in being complete operating systems and not distributions: There's no single "BSD kernel" and the projects just choose different packages that are installed by default. Each and every BSD project's kernel is a specific one in its own right. Packages built on NetBSD will not work on OpenBSD and vice-versa. The same is true for libc and basically the whole userland. Speaking of the latter: These systems are whole operating systems because they each have a so-called "base system", their own userland which is developed together. As a result there is a clear separation between OS and third-party software: A freshly installed BSD system does usually not come with even a single package installed!

While this also means that keeping the OS up to date requires other means than the package manager and that may sound weird from a Linux perspective, it's actually a great thing. On Linux the distro maintainers can never know exactly what wild combination of packages you may have installed which can make distribution upgrades go horribly sideways (we've all been there, right?). With a BSD system you know what the current system looks like and what the new one will look like. Packages generally don't interfere with the actual OS (this is not entirely true as for a workstation you may depend on e.g. a graphics driver from packages which provides a kernel module that will not be compatible after upgrading the OS, but on servers it's hard to break your system with an upgrade unless you deliberately do terrible things).

If anybody is interested in adding BSD support, I would recommend to pick one BSD first and go for that one. Usually FreeBSD is a good choice since that's the most popular one with the largest user base and by far the most often used one in commercial environments.

I will happily provide information on how the package versioning scheme works, how to query the package database, where to get repository information from, what the OS version string means and the like if it helps.

[furlongm]

Thanks for the in-depth info there!

Do you know if packages use a common naming/versioning scheme? Like NEVR?

[kraileth]

On FreeBSD packages as reported by pkg(8) look like this:

xorg-server-21.1.8_6,1

First there's the name which may contain dashes but the last dash separates the name from the version. Underscores are used to indicate an optional package revision and after a comma there's the optional epoch. So here we have xorg-server upstream version 21.1.8, 6th package revision of this version and the port has an epoch due to a switch in the upstream version scheme (they went from 6.x to 1.x in the mid 2000's when X11R6 was succeeded by the modular R7 IIRC). So for a very simple example we have XTerm:

xterm-387

Just the package name and version string as used upstream. Extremely weird version strings get normalized (e.g. if they contain an underscore). Here's another example:

ImageMagick7-7.1.0.62_7

Uppercase letters are valid but rare. Most porters choose to normalize names to lowercase. For some project FreeBSD keeps multiple major versions in the repo at the same time, for example:

ImageMagick6-nox11-6.9.12.77_6,1

This name contains another part between the name and the version. The 'nox11' indicates what is called a flavor, basically the same package but with different build-time configuration options (and often more or fewer runtime dependencies). As far as patchman is concerned, there's probably no need to handle this and it's fair enough to consider the flavor part of the package name.

Package names for software written in an interpreted language are prefixed to indicate the language and interpreter version (if applicable). For example Python's numpy module:

py39-numpy-1.25.0_2,1
py310-numpy-1.25.0_2,1
py311-numpy-1.25.0_2,1

Said package is available for Python 3.9, 3.10 and 3.11 respectively.

That's about all I can think of right now. Package information can be acquired using pkg info . The output will be two colums of package name + version and short description like this:

[...]
atril-1.26.0_20                MATE multi-format document viewer
audacity-3.3.3_1               GUI editor for digital audio waveforms
avahi-app-0.8_1                Service discovery on a local network
awesome-4.3_4,1                Highly configurable, next generation framework window manager
babl-0.1.106                   Dynamic pixel format conversion library
bash-5.2.15                    GNU Project's Bourne Again SHell
[...]

To detect the OS uname can be used with either the -o or the -s switch:

% uname -s
FreeBSD

The operating system version is not terribly complicated, but it's important to know that there's multiple branches: -CURRENT, -STABLE and -RELEASE. The first one is where the development happens. If you build the system from the latest source or install a development snapshot, at this time you get 15-CURRENT as 15.0 will be the next big release quite a while in the future. Before that happens, it will become 15-STABLE and -CURRENT will move to 16. The stable branch bears this name because the ABI is frozen so that any binary built for e.g. 14-STABLE will be guaranteed to run on any release from the same major version. Various features will be backported from -CURRENT to previous stable versions and at certain times, a new point release will be cut from XY-STABLE.

We're currently close to the new major version 14.0-RELEASE to be published. Later on 14.1-RELEASE, 14.2-RELEASE and so on will follow. In addition to the upcoming 14.0-RELEASE currently 13.2-RELEASE and 12.4-RELEASE are also supported with the latter going EOL at the end of the year, ending official support for version 12. It's not terribly uncommon to run -STABLE if you know what you're doing. The hosting company I work for has run -STABLE for years on some servers of our FreeBSD fleet. However in general it's recommended to only run -RELEASE in production.

This is what versions look like on release, but before and after there will be postfixes added. During the release engineering process the new version went through 5 beta versions (14.0-BETA1, 14.0-BETA2, ...) and right now the latest one is the (likely) final release candidate, 14.0-RC3. When errata is published and fixes were applied, the version string includes the patch level like this:

% freebsd-version 
13.2-RELEASE-p4

The freebsd-version command has three useful flags: -kru. 'k' makes it output the version of the installed kernel, 'r' reports the running kernel (so this way patchman could detect when a reboot is required) and 'u' reports the userland version. There are cases when the userland patchlevel is higher then the one reported for the kernel; this is perfectly legit and happens when the latest patch only affected the userland.