Packages and controlled updates

Packages are managed dependencies

A package manager records installed files, versions, and dependencies and retrieves packages from configured repositories. Updating repository metadata is different from upgrading installed packages. Also, installing a new library does not prove every running process has loaded it.

Choose the commands for your VM's distribution; do not mix package systems. On a Debian or Ubuntu lab VM with APT:

cat /etc/os-release
dpkg-query -W -f='${Package} ${Version}\n' bash
apt-cache policy bash
apt-get --simulate install --only-upgrade bash

The simulation uses available metadata, which may be old. Updating it requires a separate sudo apt-get update operation and network access. Read the proposed dependencies and removals before any real installation. On an RPM-based system, use that distribution's DNF/RPM documentation instead of translating flags by guesswork.

Interpret installed, candidate, and source

dpkg manages the local Debian package database. APT adds repository metadata and dependency resolution. A dependency is another package needed by the requested package. The installed version is on this machine; the candidate is the version APT currently proposes according to configured repositories and policy.

An illustrative apt-cache policy result could be:

example-package:
  Installed: 1.0-1
  Candidate: 1.0-2
  Version table:
     1.0-2 500
        500 https://configured-repository.example distribution/main Packages
 *** 1.0-1 100
        100 /var/lib/dpkg/status

The example names and versions are invented solely to explain the fields; do not add this address as a repository. It shows an available candidate differing from the installed version. Candidate and installed can legitimately be identical. A higher version string alone does not tell you whether your specific vulnerability or bug is fixed; consult the distribution's package/advisory information.

The bite's simulation asks to upgrade bash only if it is installed. It may propose dependency changes or report nothing to do. Simulation uses current metadata and does not install packages. sudo apt-get update refreshes that metadata, while sudo apt-get upgrade performs package changes after review; the earlier virtualization module rehearses that full sequence with a recovery copy.

For another read-only connection between a command and its package:

dpkg-query -L bash
dpkg-query -S /bin/bash
apt-mark showhold

The first lists files recorded for Bash. The second asks which installed package owns the given path; merged /usr layouts and the database's recorded spelling may require checking an alternate canonical path. apt-mark showhold lists packages deliberately held back. Do not unhold one merely to remove a warning: determine why it was held.

A practical maintenance record

For one package, record its installed version, configured source, candidate version, why the update is needed, and how to verify the consuming service afterward. Include whether a restart or reboot is required and when it can occur. A package downgrade may be unavailable or incompatible with data already migrated by the newer application; restoration must be designed, not assumed.

Use signed repositories following their current installation guidance. A familiar package name from an unknown repository is not sufficient provenance. Keep project-specific runtime environments separate from distribution-managed packages.

Trust and maintenance continue after download

APT's signed repository metadata helps verify the configured publisher and package integrity. It does not guarantee the publisher's software is harmless. Third-party repositories can distribute packages whose installation scripts run with administrative authority. Follow the vendor's current per-repository keyring and Signed-By guidance rather than copying an old global trust-key command.

Updates may leave old libraries in already-running processes. A full VM's new kernel package also does not replace the running kernel until the appropriate reboot. On OrbStack, the shared kernel is maintained by OrbStack. A /var/run/reboot-required notice on Ubuntu is useful if present, but its absence is not a universal proof that every application uses new code.

Automatic security updates, package holds, and patching hosts in waves are useful later topics. Their choices depend on restart tolerance and recovery, not merely on how to schedule a package command. Here, compare your installed/candidate values, identify the configured source, and explain one post-change behavior check for the MicroBank foundations fixture before moving on.

Check and revise

Does “the package install returned zero” establish that your API still works? No. Check the package result, running process version where available, and a representative application operation.

Revision: inventory → preview → recoverability → controlled update → service verification. This exercise stops at the preview and creates no installed-package change to undo. Rehearse real updates on a disposable VM before applying a shared-host maintenance policy.

Apply this to MicroBank

Inventory the tools used by the MicroBank foundations fixture: shell, curl, BusyBox, networking tools, and Git. Keep host packages separate from future Python, Java, Node, and container-image dependencies. Choose one post-update behavior check for the tool you changed, and retain its actual result. A package update alone does not validate MicroBank transaction behavior.

Keep this observation in the MicroBank readiness project.

Sources

Primary references: APT operations and simulation↗; Ubuntu package management↗.