pkgng Ships, Replacing FreeBSD's Aging pkg

The first production release of pkgng, now known simply as pkg, was announced on August 30, 2012. Baptiste Daroussin’s release message placed the first commit on September 7, 2010 and counted more than 2,000 commits from 43 contributors during the two-year development period. The result was not just a shorter command name: it replaced FreeBSD’s collection of legacy package utilities with one package manager, a structured local database, and repository-aware operations.

The old interface was a family of separate programs

FreeBSD’s earlier pkg_install suite divided common jobs among commands such as pkg_add, pkg_create, pkg_delete, pkg_info, pkg_updating, and pkg_version. Administrators could use them successfully, but the suite had grown around a package format and metadata model that made richer dependency and repository operations difficult to evolve as one coherent system.

pkgng brought installation, upgrades, removal, auditing, queries, and repository handling under the pkg command. Its local package database used SQLite rather than the legacy directory-and-file metadata layout. That made package relationships and queries explicit database operations and gave the implementation a foundation for transactions, dependency solving, and consistent machine-readable output.

Version 1.0 was a milestone, not an overnight replacement

The August 2012 announcement said pkgng 1.0 was ready for production use, but existing installations did not instantly lose the old tools. Users could install ports-mgmt/pkg, convert the local package database, and test the new workflow while compatibility and repository infrastructure continued to mature.

FreeBSD also made an important architectural distinction that remains easy to miss. The full package manager is not bundled into the base system as a permanently fixed binary. A small pkg(7) bootstrap utility in base locates or installs the current package-management tool. This lets pkg itself evolve through the package system while a newly installed base system still has a standard entry point for obtaining it.

Official repositories completed the practical transition

Package-manager software is only half of a binary-package service. Users also need signed or otherwise authenticated repository metadata, consistently built packages, mirrors, and policies for supported branches. On October 31, 2013, the project announced official pkgng repositories for FreeBSD 8.3, 8.4, 9.1, 9.2, 10.0, and 11-CURRENT on supported architectures.

That announcement stated that pkg would be the default beginning with FreeBSD 10 and that pkg_install was deprecated. It therefore marks a more useful operational milestone than saying pkgng simply “became official” at some undefined moment: the manager existed in production form in 2012, and project-built binary repositories plus a documented default followed in 2013.

FreeBSD 10 removed the legacy commands

FreeBSD 10.0-RELEASE, published in January 2014, made the break visible in the base system. Its release notes list the removal of the legacy pkg_add, pkg_create, pkg_delete, pkg_info, pkg_updating, and pkg_version programs. They also document pkg(7) as the bootstrap for the replacement and direct systems upgrading from the old package database to run pkg2ng.

That migration step mattered. Installed-package state is part of a working system, so a replacement could not responsibly assume every administrator would reinstall all third-party software. pkg2ng converted existing registrations into the new database, allowing the package-management layer to change without discarding knowledge of what was already installed.

The transition also extended beyond 10.0. A FreeBSD status report from the second quarter of 2014 described pkg as the only supported package manager for 10.0 and the then-upcoming 9.3 release, while legacy support was scheduled to end in September 2014. The staged retirement gave ports maintainers, repository operators, appliance builders, and administrators time to remove assumptions about the old command set.

Why the database and solver mattered

One command is easier to document, but the deeper improvement was having a consistent model of package state. pkg can reason about dependencies, reverse dependencies, installed versions, repository candidates, files, and package annotations through the same database and command-line framework. An upgrade is no longer merely a sequence of unrelated archive operations; the manager can calculate a plan across the requested packages and their relationships.

This does not eliminate operational judgment. Repository branches must match the intended FreeBSD release, configuration files can require attention, and administrators should review proposed removals or major dependency changes before accepting them. What pkgng changed was the quality of the information and machinery available for making those decisions.

A two-stage historical milestone

The accurate chronology is therefore more informative than a single anniversary. September 7, 2010 began the code history cited by its lead developer. August 30, 2012 delivered pkgng 1.0 after two years and more than 2,000 commits. October 31, 2013 brought official pkgng repositories and a declared FreeBSD 10 default. FreeBSD 10.0 in January 2014 removed the old base utilities and documented conversion with pkg2ng.

Together those steps explain why pkg became durable infrastructure: it combined a modern data model and unified interface with an intentionally managed migration path, rather than treating package management as a command-name cleanup.

Related:

Sources:

pkgng Ships, Replacing FreeBSD's Aging pkg_* Tools