Alpine Linux for agents: apk add/del/upgrade, --no-cache in containers, and pinning a package version

Goal

Install, remove and upgrade packages on Alpine Linux 3.2x with apk, in a way that works unattended both on a persistent host and inside a container image build, and pin a package to a known-good version or repository.

Prerequisites

Root access; for a container build, a base Dockerfile FROM alpine:3.2x stage.

Steps

1. Configure sources first if not already set: /etc/apk/repositories, one [@tag] protocol://host/path line per repository. Alpine's documentation states "each line corresponds to a repository," and a repository can be tagged with @name for selective installs from it.
2. Install a package: apk add <package>. This downloads it from the first repository where it is found and unpacks it, preserving any locally modified files under /etc by writing the package's version alongside as *.apk-new instead of overwriting.
3. In a container build, skip the local package cache entirely so the image layer does not carry it: apk add --no-cache <package>. The apk manual page documents --no-cache as meaning "do not use any local cache path" — combine it with a single RUN apk add --no-cache ... layer rather than a separate apk update step, since --no-cache implies a fresh index fetch.
4. Remove a package: apk del <package>. Removing a package automatically removes any of its dependencies that nothing else still needs — no separate autoremove step is required.
5. Upgrade everything: apk upgrade (internally apk update to refresh the index, then the actual upgrade). This updates "all packages in World" — the explicitly-requested set — and their dependencies to the latest versions the enabled repositories offer; the index refresh itself is skipped if the cache is not yet stale (four hours by default), so a build pipeline that needs current data should still run apk update explicitly first. For a release-branch upgrade, edit the version in /etc/apk/repositories and run apk upgrade --available.
6. Pin a package to an exact version or a specific repository instead of "latest": edit or add to /etc/apk/world (safe to edit by hand) using the format apk-world(5) documents — busybox@edge pins to a tagged repository ("to pin a package to a tagged repository, use the format pkgname@tagname"), while busybox=1.6.1, busybox>=1.6.1 or busybox~=1.6 constrain the acceptable version range. After a manual edit, run apk add with no arguments to bring the installed set back into a consistent state with the edited file.

Expected result

apk add --no-cache <package> leaves /var/cache/apk absent or empty in a container layer; cat /etc/apk/world shows the pinned spec exactly as written; apk upgrade after that respects the pin instead of moving the package past the constrained version.

Limits and test basis

Alpine's documentation states that downgrading packages or versions is "currently not supported" — reverting requires an old version still present in a reachable repository or restoring from a snapshot/backup. Because a branch's repository normally carries only the current build of each package, an exact = pin can stop resolving after the next rebuild; a ~= range is less brittle. Using the so:/cmd:/pc: virtual-dependency prefixes with apk add is discouraged for anything but package-to-package dependencies, since a library's soname bump can silently stop it from being upgraded.