Fixing Package Conflicts and Broken Dependencies in Haiku

Because Haiku’s package management is built on packagefs mounting packages rather than extracting them, most package problems are fixable by changing which packages are activated — not by hunting for stray, partially-installed files scattered across the file system the way a traditional package manager’s failures often require.

Step 1: check what’s actually activated

pkgman list

This lists every currently active package — confirm the package you expect to be present actually is, and check for an unexpectedly duplicated or outdated version sitting alongside a newer one.

Step 2: check for a dependency version mismatch

pkgman resolve-dependencies

If a package needs a library version that isn’t currently activated, this surfaces the mismatch directly rather than leaving you to guess from a generic runtime error when the affected application actually tries to launch.

Step 3: use HaikuDepot to check for a broken or partial installation

HaikuDepot (Haiku’s graphical package manager) shows the state of each package clearly and lets you retry or repair activation for a specific package without needing to work from the command line:

HaikuDepot → search for the package → check its listed status
                                        (Installed / Available / Update available)

A package stuck in an inconsistent state here is usually resolved by simply deactivating and reactivating it — an operation that’s cheap and low-risk specifically because activation doesn’t involve re-copying files, only changing what packagefs currently merges into view.

Step 4: roll back a problematic update

If a recent update introduced the problem, Haiku’s package system keeps previous package states available for rollback:

pkgman rollback

Because deactivating a package is close to instantaneous (see packagefs for why), rolling back a bad update is a fast, low-risk way to confirm whether a specific update is actually the cause before investigating further.

Step 5: check for a leftover, manually-placed file conflicting with a package

Rarely, a file manually placed outside the package system (copied directly into what looks like a system directory) can conflict with what a package expects to provide in that same location. Since /boot/system is normally an assembled, packagefs-managed view rather than a directory you write into directly, a manually-placed file here is usually the actual root cause if package activation/deactivation alone doesn’t resolve the problem — check /boot/system/non-packaged/ specifically, which is where manually-installed files are meant to live separately from packaged content.

Step 6: reinstall a specific package cleanly

pkgman uninstall <package-name>
pkgman install <package-name>

Because this only changes which .hpkg files packagefs includes in its merge, a clean uninstall/reinstall cycle is a safe, low-cost troubleshooting step to reach for earlier than it would be on a system where installation means physically re-copying every file.

Why package problems are usually cheap to fix here

The same property that makes package activation instantaneous — packages are mounted, not extracted — also makes most package-related fixes safe and cheap to attempt: deactivating, rolling back, or reinstalling a package doesn’t risk leaving stray files behind the way an interrupted extraction-based install or uninstall can on other systems, which is exactly why working through activation state first, before assuming something is deeply broken, resolves the large majority of these problems quickly.