Packagefs: Instant, Reversible Package Activation Without Unpacking

Traditional package managers install software by extracting a package’s contents and copying individual files into the right places across the file system — /usr/bin, /usr/lib, /etc, and so on — then recording, separately, which files belong to which package so they can be found and removed again later. Haiku’s packagefs takes a fundamentally different approach: packages are never unpacked onto disk at all.

Packages as mounted file systems, not archives to extract

A .hpkg package file is itself readable directly as a virtual file system — packagefs mounts one or more activated packages together, presenting their combined contents as ordinary-looking directories:

/boot/system/          ← not a real directory tree on disk;
                          a virtual view assembled by packagefs
                          from every currently-activated package

Activated packages (each an .hpkg file, never extracted):
  - haiku.hpkg
  - webpositive.hpkg
  - some_app.hpkg
        │
        ▼ packagefs mounts and merges all of them
/boot/system/apps/WebPositive     ← appears here, but the actual
                                     bytes still live inside
                                     webpositive.hpkg, unextracted

Looking at /boot/system shows what looks like an ordinary directory tree, but it’s a live, virtual merge of every currently-activated package’s contents — none of those files were individually copied there.

Why this makes activation and rollback effectively instant

Installing a package under this model means telling packagefs to include one more .hpkg file in the merge — no file copying, no per-file extraction work proportional to the package’s size. Removing a package, or rolling back to a previous state, is the same operation in reverse: stop including that package in the merge, and its files simply stop appearing, instantly, because they were never physically written to the visible file system tree in the first place.

Where this idea came from

The vision for package management on Haiku was first drafted in January 2011, but the project that actually shipped — including packagefs itself — went live in September 2013, developed under funded contracts (Ingo Weinhold and Oliver Tappe were the two contractors most associated with this work). It later became a defining feature of Haiku’s first beta release in 2018, discussed in more detail in the news post on package management shipping.

The trade-off: packages are read-only, by design

Because a package’s contents are mounted rather than copied, they’re inherently read-only from an installed-application’s perspective — an application can’t simply write a new file into what looks like its own installation directory the way it might on a system using traditional extraction-based installs. Haiku addresses this the same way most modern package systems do regardless of their underlying mechanism: applications are expected to write their actual runtime data (settings, caches, user files) to separate, genuinely writable locations, not into their own package-provided directory tree.

Why this matters beyond just installation speed

Instant, reversible activation isn’t just a convenience — it removes an entire class of “partially installed” or “partially removed” failure states that file-copying package managers can end up in in if interrupted midway (a system crash mid-extraction, a disk filling up partway through copying). Because activating or deactivating a package is close to an atomic operation — updating which packages packagefs currently merges together — rather than a long sequence of individual file operations that could be interrupted partway through, the system spends far less time in a state where package management has broken the file system it’s supposed to be managing.