RTFM · Packages
Managing packages with APK
APK organises around six verbs and one mental model: repositories publish signed index snapshots; world records what you asked for; commits reconcile the difference.
The verb set
| Command | Effect |
|---|---|
| apk update | refresh repository indexes |
| apk add pkg [pkg...] | install, then commit |
| apk del pkg | remove package and constraint |
| apk upgrade | update tracked packages to newest compatible |
| apk fix | repair/reinstall inconsistent pieces without touching world |
| apk search term | query available by name/description |
| apk info [pkg] | installed-package details (files, deps, description) |
| apk list --installed | everything currently present |
| apk policy pkg | which repositories offer which versions |
| apk dot pkg | render dependency graph as graphviz |
Searching and evaluating before installing
apk search ripgrep
apk policy ripgrep # repo versions offered
apk info ripgrep # after install: what got pulled inPreview habit: test unfamiliar packages on a throwaway VM or container first, or review dependency output before admitting a commit on production machines.
Repositories configuration
/etc/apk/repositories lists sources, one per line.
cat /etc/apk/repositories
apk update # mandatory after edits
apk policy curl # confirm availability post-editAdding random unsigned mirrors converts your package manager into arbitrary-code deployment. Stick to official repositories or mirrors you operate and sign yourself.
Upgrading discipline
apk update
apk upgrade --dry-run # preview
apk upgradeKernel upgrades deserve the dedicated kernel-chapter ritual: verify the installed image, update bootloader config, retain the prior kernel entry, deliberate reboot while calm.
Removing things properly
apk del ripgrep
apk info # confirm landscapeWhy APK suits the DIY thesis
Everything happens locally from signed repositories you can audit, cache, pin, and replicate offline. No phone-home, no subscription entitlement, no rented update channel — the same freedom arguments underpinning Saphira itself. Your package toolchain belongs to you.
Prove it works: confident stewardship
system upgraded across a release boundary with a documented rollback path, rehearsed on a scratch machine before production trust was placed.
Did we miss something?
If this page left something unanswered, found an error, or there is another subject you would like documented, tell us. Saphira’s documentation grows from real problems people need to solve.
Send feedback or request a new section →
Prefer not to do it yourself?
Everything needed to do the work yourself is documented here and remains free — we charge for human time, not for withholding knowledge. Sometimes the missing resource is simply time. The same people who build Saphira can provide paid professional help with implementation, migration, troubleshooting and administration.