Packaging FreeBSD base

About PkgBase

PkgBase is the FreeBSD base operating system (OS), packaged for use with pkg(8).

pkg is already the norm for installing and updating ported software that is separate from base.

PkgBase aims to replace:

PkgBase complements building and installing from source. In particular:

Status

Publication of official packages began in October 2023. Although packages are official:

Packages are published for architectures that are listed in make targets.

Branch

Frequency

URL

main

twice daily – 12:00 and 00:00 UTC

https://pkg.freebsd.org/${ABI}/base_latest

main

weekly – Sunday at 12:00 UTC

https://pkg.freebsd.org/${ABI}/base_weekly

stable/14

twice daily – 12:00 and 00:00 UTC

https://pkg.freebsd.org/${ABI}/base_latest

stable/14

weekly – Sunday at 12:00 UTC

https://pkg.freebsd.org/${ABI}/base_weekly

releng/14.0

twice daily – 12:00 and 00:00 UTC

https://pkg.freebsd.org/${ABI}/base_release_0

releng/14.1

twice daily – 12:00 and 00:00 UTC

https://pkg.freebsd.org/${ABI}/base_release_1

Changes to releng (RELEASE) branches are infrequent.

Publication occurs only if a package changes.

In Bugzilla:

Related resources:

Overview

PkgBase comprises a few hundred packages with the default build (empty src.conf(5) and make.conf(5)) for amd64. The number of packages depends on several factors.

In most cases, a runtime binary is split into multiple components. Debugging symbols and most shared libraries are packaged individually. 32-bit is bit packaged separately.

Initial setup

Prerequisites:

Create a directory for repository configuration files, then add a FreeBSD-base.conf file:

Update repositories:

Install base packages from the FreeBSD-base repo:

Finally – do not skip this – attend to:

.pkgsave files

If a file on disk differs from what is inside the package holding the file, then pkg(8) will rename the file – using a .pkgsave suffix – before installing what's packaged.

This is the same for config files, pkg(8) will not be able to merge them all if they were modified.

The six steps below are essential.

If a system was more broadly customised – beyond sysctl.conf(5) – before initialisation of pkgbase, then attention to other .pkgsave files may be required.

To interactively find and copy all such files, you can run this command (in sh(1)):

A non-interactive approach:

Upgrades

pkg upgrade alone is OK when there is no change to the base version level.

Minor version upgrades

From 14.0 to 14.1, for example.

  1. pkg upgrade --yes --repository FreeBSD-base

  2. restart the OS
  3. upgrade ports (using available packages).

Major version upgrades

When attempting a major upgrade of FreeBSD (e.g. from 11 to 12), you may find the following error:

For this case, the following command will allow a successful upgrade:

Building

To build base and kernel packages and install them to a jail/boot environment directory (14.1 host, 32 cores available):

Caveat: /usr/obj/usr/src/repo/FreeBSD:14:amd64/14.1 will not be valid from within the chroot/jail/boot environment and must be populated from the build host in some way.

Outstanding

No method to notify users when pkg upgrade does not include a new base package. If a file moves to a new package, then an upgrade (without the new package) might inappropriately remove the file. This problem was noticed after base 0648b47f0606 (2016), which moved /etc/rc.d/[zfs|zvol] from the FreeBSD-runtime package to the new FreeBSD-zfs package.

Goals, and additional unresolved issues

The following items need to be addressed before PkgBase can be considered for production use:

Retrospective

A call for testing was made in March 2016.

Major blockers and critical issues appeared to be resolved.

Glen Barber's notes from the packaging session at the 2017-08 BSDCam devsummit

Userland packages sets – can someone clarify what exactly this means?

TODO:

Package containing the source tree that a [base] package set was built from. Note: while I think this is a good idea, I have concerns about behavioral consistency between pkg upgrade and svn up ''/usr/src''. Some things that come to mind immediately are:

  1. locally-patched source trees and losing patches on pkg upgrade;

  2. svn up changing checksums recorded in the pkg(8) database;

  3. ultimately "Which one wins?" in an update of /usr/src?

Add SVN rev of source tree to pkg metadata (or equivalent, plus indicate if the tree has been modified similarly to uname(1)) (Note: committed as r322412.)

RDBMS-backed web application to collect file checksums from every official package and allow users to verify files on-line.

Using pkgdb as an IDS? Support pkg audit?

Document FreeBSD 14.1 the source package.


CategoryProject CategoryTodo

PkgBase (last edited 2024-07-23T15:18:41+0000 by MateuszPiotrowski)