Skip to content

Instantly share code, notes, and snippets.

@schmonz
Last active December 13, 2023 18:43
Show Gist options
  • Save schmonz/6270a81495a8e2091cbb4e693e48e149 to your computer and use it in GitHub Desktop.
Save schmonz/6270a81495a8e2091cbb4e693e48e149 to your computer and use it in GitHub Desktop.
pkgcenter intro for schmonzes and maybe other people

pkgcenter

pkgcenter is a tool for people who

  1. Rely on native Unix system packages for software dependency management
  2. Must manage dependency risks beyond the capabilities of native Unix package tools

Real-world example 1

Let's say you're on Enterprise Linux 7 and working through the EL9 upgrade. Some RPMs fail to install, with errors about build-id.

After some research, you learn that another way dnf deems packages "conflicting" is if they're signed and an ELF object with identical checksum exists in both -- regardless of whether they install to unique locations in the filesystem -- and that Red Had has recently enabled package signing by default.

Don't you wish you could take a set of signed binary RPMs from upstream, remove the signatures, and turn that into a set of newer-versioned unsigned binary RPMs?

Real-world example 2

Let's say you're on FreeBSD, there's a new version of some software you rely on, and someone has made it available in ports. You've built a binary package, tested as well as you can, and promoted it to production.

Something goes wrong in production.

You don't have time to think about the problem yet; you first need to restore a working version in seconds or minutes. Oh, and the build takes hours. Oh, and deployment requires that the package version sort "newer" than what's installed.

Don't you wish you could easily extract the contents of the previous binary package, apply a few transforms, and turn that into a newer-versioned binary package?

About these examples

If you don't have these kinds of expectations for the reliability of software in production, you don't need pkgcenter yet.

If you're concerned with these risks, but already feel comfortable with the ways you're mitigating them, you don't need pkgcenter yet.

If you're not convinced you're managing these risks well enough today, let alone when new and exciting kinds of breakage get invented, you need enhanced tooling to cost-effectively address structural problems in software dependency risk management. You need pkgcenter.

Tell me more

Currently supported:

  • OS native package tools: NetBSD pkg_add or pkgin, FreeBSD pkg, Red Hat/CentOS Linux rpm
  • make programs: NetBSD and FreeBSD [b]make, FreeBSD [f]make, GNU make
  • Shells: Linux bash 4.x, macOS bash 3.x, Debian dash, FreeBSD sh

pkgcenter relies on the OS's native source packages to focus on

  • Acquisition
  • Compilation
  • Installation
  • Packaging

So that pkgcenter can focus on

  • Versioning
  • Auditing
  • Packaging

Let's look at some ways to use pkgcenter.

Build a set of binary packages from current source tree

For NetBSD: XXX

For FreeBSD: XXX

For CentOS: XXX

Build a set of binary packages from older source tree

Audit installed packages

Pin packages at particular versions

Build only needed packages after OS update

e.g. EL7 -> EL9

....

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment