Manager augmentations

Package managers are not comparable: some ship advanced features others lack. Rather than expose that unevenness, mpm backfills the missing pieces on top of the native tools, so every manager gains a consistent baseline.

Managers gaining features

Each ✅ below is a capability mpm synthesizes for a manager that does not provide it natively. The table renders straight from the capability declarations in the manager implementations, so it never drifts from the code. The rest of this page explains each column.

Manager

Full upgrade --all

Orphan sweep

Explicit install

Exact search

Extended search

Cooldown gate

apk

✅

apm

✅

apt

✅

apt-cyg

✅

✅

apt-mint

✅

✅

aptitude

✅

asdf

✅

✅

✅

aura

✅

✅

✅

bob

✅

✅

cargo

✅

✅

choosenim

✅

✅

chromebrew

✅

✅

clib

✅

✅

composer

✅

conda

✅

✅

deb-get

✅

✅

dkp-pacman

✅

✅

✅

dnf

✅

✅

✅

dnf5

✅

✅

✅

dotnet

✅

✅

eopkg

✅

fink

✅

✅

flatpak

✅

✅

✅

✅

gem

✅

getnf

✅

✅

gext

✅

✅

gh-ext

✅

✅

ghcup

✅

✅

guix

✅

✅

haxelib

✅

✅

ips

✅

✅

juliaup

✅

✅

krew

✅

✅

luarocks

✅

✅

✅

lure

✅

✅

mamba

✅

mas

✅

✅

✅

micro

✅

✅

microdnf

✅

✅

micromamba

✅

mise

✅

nala

✅

✅

✅

nimble

✅

✅

nix

✅

✅

npm

✅

opam

✅

✅

opkg

✅

✅

pacaur

✅

✅

✅

pacman

✅

✅

✅

pacstall

✅

✅

pamac

✅

✅

✅

paru

✅

✅

✅

✅

pearl

✅

✅

pikaur

✅

✅

✅

pip

✅

pkcon

✅

✅

pkg

✅

pkg-tools

✅

✅

pkgin

✅

✅

pkgit

✅

✅

pnpm

✅

prt-get

✅

✅

pwsh-gallery

✅

pyenv

✅

✅

scoop

✅

✅

sfsu

✅

✅

shelly

✅

✅

✅

slapt-get

✅

✅

snap

✅

✅

soar

✅

✅

sorcery

✅

✅

spack

✅

swupd

✅

✅

tazpkg

✅

✅

tlmgr

✅

✅

trizen

✅

✅

✅

urpmi

✅

✅

uv

✅

vagrant

✅

✅

✅

vcpkg

✅

✅

whalebrew

✅

✅

xbps

✅

✅

✅

yarn

✅

✅

yarn-berry

✅

✅

yay

✅

✅

✅

yum

✅

✅

✅

zef

✅

✅

zeroinstall

✅

✅

zvm

✅

✅

zypper

✅

Free upgrade --all

Some managers cannot upgrade every outdated package in a single command. pip, for instance, has no full-upgrade subcommand. When a manager only knows how to upgrade one package at a time, mpm synthesizes the bulk operation: it lists the outdated packages and upgrades them one by one, so mpm upgrade --all works everywhere. The --plan option shows the synthesis, one upgrade command per outdated package where a native bulk upgrade is a single command:

$ mpm --uv --plan upgrade --all
/opt/homebrew/bin/uv --color never --no-progress pip install --upgrade anyio
/opt/homebrew/bin/uv --color never --no-progress pip install --upgrade docutils
/opt/homebrew/bin/uv --color never --no-progress pip install --upgrade platformdirs
/opt/homebrew/bin/uv --color never --no-progress pip install --upgrade pyproject-fmt
/opt/homebrew/bin/uv --color never --no-progress pip install --upgrade sphinx-autodoc-typehints

The Full upgrade --all column above lists the managers relying on this backfill.

Free orphan sweep

Some managers can list their orphaned dependencies but have no verb to remove them all in one go. pacman is the canonical case: Arch users chain the two native primitives by hand, with the classic pacman -Rns $(pacman -Qtdq) idiom. When a manager implements the orphans listing and per-package removal but no native sweep, mpm cleanup --orphans synthesizes the sweep in-process: list the orphans, remove each one (recursively where the manager supports it, so every listed root takes its own now-orphaned subtree along), then re-query and repeat until the listing settles, since removing an orphan can orphan its own dependencies.

$ mpm --pacman cleanup --orphans

The Orphan sweep column above lists the managers relying on this backfill.

Explicit installs survive orphan sweeps

A manager records why each package is installed: on explicit request, or only as a dependency of another package. Its orphan sweep removes a dependency once nothing needs it. Some managers do not change that record when asked to install a package they already hold as a dependency. pacman, for instance, reinstalls the package and keeps its old install reason. A later mpm cleanup --orphans could then remove a package the user asked for.

When a manager has a command that changes only the install reason, mpm install and mpm restore run it after they install a package that was already present:

$ mpm --pacman install jq

The Explicit install column above lists the managers relying on this backfill.

Supply-chain cooldown gate

A release-age cooldown needs a mechanism inside the manager to filter versions by publication date, and most managers ship none. Where the manager’s install unit is a self-contained artifact, or its whole transaction is enumerable with a native exclusion flag, mpm synthesizes the gate itself: it probes each package’s publication date through the manager’s own CLI, reading a server-set timestamp the package’s author cannot backdate, and holds back any release younger than the window.

$ mpm --flatpak --cooldown "7 days" upgrade --all

The Cooldown gate column above lists the managers relying on this backfill. The probe’s admission rules, per-manager mechanisms and limits are covered by the cooldown page.

Universal augmentations

The table above is selective: each ✅ backfills a capability only some managers lack. A second class of augmentation applies to every manager mpm drives, whether or not its native CLI cooperates.

Safe --dry-run everywhere

mpm intercepts each state-changing call and logs it instead of running it, so any manager becomes previewable even when its own CLI has no dry-run mode:

$ mpm --dry-run --apt upgrade --all
warning: Dry-run: (...)

Inspect the plan before running

mpm --plan <operation> prints the exact package-manager commands a state-changing operation would run, without running them. Unlike --dry-run, which simulates every call and so leaves install, remove and upgrade --all unable to resolve what they would do, plan mode still runs the read-only lookups those operations need, then captures only the mutations, one copy-pasteable line per command on stdout:

$ mpm --plan --brew upgrade --all
HOMEBREW_NO_ANALYTICS=1 HOMEBREW_NO_ENV_HINTS=1 HOMEBREW_NO_AUTO_UPDATE=1 /opt/homebrew/bin/brew upgrade --quiet --yes --formula

Each line carries the resolved binary path and the forced environment, so the plan doubles as an audit trail and pipes straight into a shell.

A report of what each command changed

A native command reports what it changed in its own words, or not at all. mpm reads each manager’s installed inventory before and after it runs install, remove, upgrade, restore or cleanup --orphans, and diffs the two readings, so every manager gets the same report. On the trail, upgrade --all counts the outcomes of each manager, and the orphan sweep counts its removals beside its category:

$ mpm --brew upgrade --all
✓ brew.upgrade_all (1 upgraded) (15.6s)
✓ Upgraded 1/1 managers

The table follows on stdout, one row per package with its From and To versions and its Status:

Status

Meaning

🆙 upgraded

The installed version moved to a newer one.

⏪ downgraded

The installed version moved back to an older one.

🆕 installed

A package the command installed, or a dependency it pulled in.

🗑️ removed

A package the command removed, or one it dropped along the way.

⏸️ held

Still outdated: the cooldown holds it back.

⏳ still outdated

Still outdated for another reason: a failed build, a pinned package, or one the native command leaves alone.

Only an upgrade names the packages it expects to move, so only an upgrade reports held and still outdated rows. The table takes the format --table-format selects and the columns --columns keeps. A serialized format like JSON carries the bare status words, for a script to match. The report costs one installed listing on each side of the command, plus one outdated listing before an upgrade. A manager whose listing carries no versions gets no report, and neither does a --dry-run or --plan run, which moves nothing.

Comparable versions across schemes

Package managers report versions in mutually incompatible schemes: semver, PEP 440, calendar versioning, Debian epochs, Gentoo suffixes, and more. Rather than a parser per format, mpm runs every version through a single tokenizer that yields a good-enough ordering, so outdated shows a meaningful installed-to-latest comparison even for managers whose native output never could.

Standard package URLs (purl)

Every package mpm reports carries a purl identifier that the native tools do not emit. It is the same identifier that powers mpm sbom, giving every manager a portable, tool-agnostic package name.

One sudo prompt, uniform policy

Managers disagree on whether an operation needs root. mpm applies a consistent policy: system managers (apt, dnf, pacman, …) escalate, user-level managers do not. Before a state-changing command it probes the sudo credential cache and silently keeps a warm one alive; only a cold cache on an interactive terminal draws a single up-front password prompt, naming the escalating managers and branded [mpm], instead of letting each manager prompt mid-run. Off a terminal, managers that need root fail fast rather than hanging on a hidden prompt.

Managers that run sudo from inside their own commands (cask, fink) reuse the warm cache too; on a cold one, a mutating call that goes silent on a terminal draws a warning pointing at the possibly hidden password prompt. See privilege escalation for the full story.