The world

The world is the set of packages you want on purpose. Every other installed package is there only because something in the world needs it. After each change, zenpac brings the system to exactly what the world needs: zp remove takes an entry out of the world, and every package nothing needs any more goes with it.

An entry of the world is one of:

• a package, by name, with a version constraint ('nano>=9') or a repo (tool@masterfix/tools) if you asked for one;
• a held package, which keeps its installed version through upgrades;
• a virtual group (zp install --virtual build-deps gcc make): one name for a set of members, which go together (see build dependencies).

zp install, satisfy, remove and world apply change it. The world is kept in the local store, nowhere else.

Looking at it

$ zp world
World (3)
   build-deps        gcc, make>=4
   glibc       held
   nano

zp world show is the same. With --json, it’s {"world": [{"spec", "hold", "members"}]}.

Marking packages

zp mark changes the world only. It never installs, upgrades or removes a package:

Command	What it does
zp mark manual <name>…	The installed packages go into the world, so they stay when nothing else needs them
zp mark auto <name>…	The packages leave the world and stay installed while something needs them
zp mark hold <name>…	The packages keep their installed version through upgrades. A package installed as a dependency goes into the world, held
zp mark unhold <name>…	Held packages upgrade again

• mark auto on a package nothing else needs would remove it, so it’s refused, with the packages that would go. That’s what zp remove does.
• Virtual groups can’t be held, only packages. mark auto takes a group out of the world if everything in it is still needed.
• Marking twice (manual on a package already in the world, unhold on a world entry that isn’t held) changes nothing and isn’t an error.

World files

zp world export prints the world as a world file, and zp world apply <file> makes a world file the world on another system (or the same one, later): it plans what the new world needs, installs it, removes what nothing needs any more, shows the plan and asks first, like install (-y, -s). Installed packages keep their versions; zp upgrade is a separate step. If the system is behind the repos, applying a world that installs anything is a partial upgrade, and zenpac asks first (-y upgrades along, --allow-partial doesn’t).

$ zp world export > world.toml
$ zp --root /mnt world apply -y world.toml

A world file is TOML:

# The world of a Zen system: what's installed on purpose.
# Apply it with `zenpac world apply <file>`.
version = 1
packages = ["glibc", "nano>=9", "tool@masterfix/tools"]
held = ["glibc"]

[virtual]
build-deps = ["gcc", "make>=4"]

Key	Meaning
version	The format’s version, 1. Required: zenpac refuses a version it doesn’t know
packages	The package entries, as zp install takes them: a name, with a version constraint or a repo
held	The names of package entries that keep their installed version
[virtual]	The virtual groups: each key is a group’s name, its value the members (at least one)

Other keys are errors, and so is a name that’s in the file twice, a held name that isn’t in packages, and a group named like a package.