Fixing Slow Haiku Package Installs Without Interrupting the Transaction
Measure slow Haiku installs by repository refresh, download, solver, disk transaction, packagefs activation, and scripts before intervening.
A package install passes through repository metadata, dependency solving, downloads, disk writes, package-daemon transaction, writable-file/scripts, and packagefs activation. Identify which phase is slow before cancelling. Interrupting administrative moves can turn a performance complaint into recovery work.
Reproduce from Terminal
If HaikuDepot appears stalled, note its current task, then retry a safe equivalent with pkgman only after the original transaction completes or is cancelled through the UI. Preserve timestamps and all progress/error output. Do not run two package managers concurrently against the same installation location.
Separate pkgman refresh time from pkgman install <package> or full-sync. A slow refresh implicates repository/network/metadata. A fast refresh followed by long download, solve, or apply phases narrows the problem differently.
Record package names, versions, system versus home scope, enabled repositories, Haiku revision/architecture, and whether the operation repeats. One large package on slow media is not evidence that every install regressed.
Measure network and repository work
Use pkgman list-repos and disable one slow/unreachable third-party repository through Preferences → Repositories. Keep official branch/architecture URLs unchanged. Test DNS, HTTPS, system clock, and throughput to the failing repository.
Repository refresh can download sizable index metadata; the time depends on mirror, network, disk cache, and parsing. Compare the same command twice and record bytes/time if output provides them. Do not erase all caches merely because the first refresh is slower.
If downloads pause, inspect free space and network errors. A full cache/volume and a mirror timeout can look like no progress. Preserve the exact URL/status without exposing private repository credentials.
Inspect solver and transaction phases
Read the interactive package plan. A large full-sync, provider change, or cross-scope dependency conflict may require far more solving than installing one leaf application. Do not use -y while diagnosing because it hides the review point.
During apply, observe disk I/O, CPU, and free space without modifying packages/administrative. The package daemon moves HPKG files, maintains old states, handles writable files/scripts, and asks packagefs to activate the new set. Post-install or pre-uninstall scripts can add package-specific delay.
Distinguish a quiet interface from a stopped process. Record whether package files, transaction timestamps, CPU, disk I/O, or logs still change. Lack of a moving progress bar alone is insufficient justification to interrupt a transaction.
Slow USB disks, failing media, BFS errors, or nearly full volumes affect package transactions. Check syslog and DriveSetup/device health when stalls align with I/O errors. Do not repeatedly power-cycle a disk that reports faults.
Avoid destructive “cleanup”
Never delete the current activated-packages, active transaction-..., or state directories while an update runs. They encode consistency and rollback. Wait for the process or supported cancellation to finish, then reboot into the previous package state if the new state cannot start.
Clean old states/caches only through current documented package tools and after verifying which state is active. Preserve at least one known-good boot state. Manually moving HPKG files to accelerate a solver bypasses repository/dependency intent.
If one package script is stuck, capture its process/thread and logs rather than killing the daemon. Report the package and exact script/action to its maintainer.
Establish a useful performance report
Repeat one defined operation with warm and cold metadata, recording time for refresh, solve/download, apply, and activation. Include filesystem/device, free space, repositories, package count/size, revision, CPU/RAM, and syslog errors.
Compare a previous package state only if the same repository operation can be reproduced. After a fix, verify another install/uninstall and normal reboot. Performance is resolved when the identified phase improves without losing package consistency or rollback state.
Related:
- Fixing Package Conflicts and Broken Dependencies in Haiku
- Packagefs: Instant, Reversible Package Activation Without Unpacking
Sources: