Skip to content
Haiku OSFix Published Updated 4 min readViews unavailable

Fixing Package Conflicts and Broken Dependencies in Haiku

Fix Haiku package conflicts by inspecting installed scopes and solver plans, synchronizing trusted repositories, and using bootable states.

Haiku package conflicts are solver and activation-state problems, not a reason to replace individual files in /boot/system. packagefs presents immutable HPKG contents, while the package daemon validates dependencies/conflicts and activates a consistent set. Preserve the proposed transaction and repository configuration before changing them.

Inventory installed packages and scopes

The current pkgman source documents this installed-package listing:

pkgman search -a -i -D

-a selects all, -i limits to installed packages, and -D shows installation locations/repository versions. Record whether the conflicting package is in system or home scope. A user-scope provider can affect resolution differently from the system package you expected.

Use pkgman info <package> and HaikuDepot for package details. Tracker’s Get Info → Attributes can show SYS:PACKAGE for a visible packaged file. Do not rely only on filename; package metadata resolves named provides such as libraries, commands, applications, and add-ons.

Read the solver’s proposed change

Retry the intended pkgman install, uninstall, update, or full-sync interactively and read every proposed removal, downgrade, replacement, and conflict. Do not add -y while diagnosing. Save the complete error and plan.

Package metadata can declare requires, provides, conflicts, replaces, and compatible version floors. A conflict may be intentional protection against two providers owning incompatible paths or ABIs. Forcing both HPKGs into packages does not make them compatible.

The pkgman resolve-dependencies subcommand is a developer-oriented command that requires explicit package files and repository directories; it is not a parameter-free health check for the installed system. Normal install/update commands already invoke the solver.

Verify repositories before full synchronization

Run pkgman list-repos and compare enabled official repositories with the installed stable/nightly branch and architecture. Disable stale third-party repositories temporarily through Preferences → Repositories rather than deleting caches first.

If repositories are correct, pkgman full-sync synchronizes installed system packages and may downgrade or remove packages to match. Review the interactive plan and back up important data. Use pkgman full-sync -H separately only when home-scope synchronization is intended.

Do not mix one current repository with a historical base URL just to satisfy a single library. A coherent repository snapshot is more important than the highest version string.

Recover with package states

If an update made the system or application unusable, open Boot Loader Options and select the last package state from before the transaction. There is no documented pkgman rollback command in current source; rollback at boot uses retained administrative state_... directories.

Once booted into a working state, record working/failing Haiku revisions and package versions. The official downgrade guide explains how to point the Haiku repository at an available historical revision and run full-sync for a permanent downgrade. Do not improvise a repository URL without checking availability.

Do not edit packages/administrative/activated-packages or move files among state_... directories by hand. They encode a consistent transaction and boot recovery history. Use the boot loader and Package Kit tools so package files, writable-file actions, and activation records remain synchronized.

Rollback does not revert user data or settings. Back up application state before opening it with older binaries if the update may have migrated formats.

Check non-packaged shadowing

Inspect /boot/system/non-packaged and the corresponding home non-packaged hierarchy for manually installed libraries, commands, or add-ons with the same names as package content. packagefs deliberately exposes these writable locations; their files are not managed by the solver.

Move a suspect manual file to a backup location, reboot/restart the affected service, and retest. Never try to delete the packaged counterpart from the read-only virtual hierarchy. If local software is required, convert it to an HPKG with accurate dependency metadata.

Before uninstalling a package, inspect the solver plan for dependent removals. A remove/reinstall can verify a corrupt HPKG download, but it may reset availability and run package scripts; it is not automatically consequence-free.

Report and verify

Attach pkgman list-repos, installed package listing, exact command/error, proposed solver plan, Haiku revision/architecture, and whether the conflict is system or home scope. For a bad HaikuPorts recipe, report package metadata and expected provider to HaikuPorts; for Package Kit solver/daemon behavior, report to Haiku.

After resolution, reboot if system packages changed, repeat the original application/service test, and run the installed-package inventory again. Keep the prior boot state until the corrected configuration has passed normal boot and update twice.

Related:

Sources:

Comments