Boot Volume Directory Structure

This is the directory layout of the boot volume:

common
	add-ons
	apps
	bin
	boot
	cache*
	data
	develop
	documentation
	lib
	non-packaged*
	packages*
	preferences
	settings*
	var*

home/config
	<like common>

system
	add-ons
	apps
	bin
	boot
	data
	demos
	develop
	documentation
	lib
	packages*
	preferences
	servers

	haiku_loader**
	kernel_<arch>
	runtime_loader

trash

The structure mostly equals the pre-package management directory structure with the following changes:

• The develop directory has been removed and its contents has been moved to the system/develop and common/develop directories as appropriate.
• The include directory has been removed. Its contents lives in develop/headers now.
• optional has been removed. Optional features can just be installed via the package manager.
• common/share and common/etc have been removed. Their contents goes to common/data, common/documentation, or common/settings as appropriate.
• apps and preferences have been moved to common for consistency.
• common, home/config and system each sport a packages directory, which contains the activated packages.
• common, home/config and system themselves are mount points for three instances of the packagefs, i.e. each contains the virtually extracted contents of the activated packages in the respective packages subdirectories. The directories marked with * are "shine-through" directories. They are not provided by the packagefs, but are the underlying directories of the boot volume. Unlike the other directories they are writable.
• common and home/config each contain a directory non-packaged which has the same structure as their parent directory minus the shine-through directories. In the non-packaged directories software can be installed the traditional -- non-packaged -- way.
• haiku_loader requires special treatment. While it is contained in the system package, it also needs to be extracted to the boot volume (also to system), since otherwise the stage one boot loader wouldn't be able to load it (that would theoretically be possible, but there's just not enough space in the boot block for the code dealing with the package format).