## Comparison with "package managers"

Because OSTree is designed for deploying core operating systems, a comparison with traditional "package managers" such as dpkg and rpm is illustrative. Packages are traditionally composed of partial filesystem trees with metadata and scripts attached, and these are dynamically assembled on the client machine, after a process of dependency resolution.

In contrast, OSTree only supports recording and deploying complete (bootable) filesystem trees. It has no built-in knowledge of how a given filesystem tree was generated or the origin of individual files, or dependencies, descriptions of individual components. This means that, for example, if you are distributing software which is licensed under the GNU General Public License, the burden lies with the tool generating these filesystem trees to ensure sufficent metadata is included for compliance.

The OSTree core emphasizes replicating read-only OS trees via HTTP, and where the OS includes (if desired) an entirely separate mechanism to install applications, stored in `/var` if they're system global, or `/home` for per-user application installation.

However, it is entirely possible to use OSTree underneath a package system, where the contents of `/usr` are computed on the client. For example, when installing a package, rather than mutating the currently running filesystem, the package manager could assemble a new filesystem tree that includes the new package, record it in the local OSTree repository, and then set it up for the next boot. To support this model, OSTree provides an (introspectable) C shared library.