Instruction 01-package-management-and-safe-system-updates: Reading

Safe updating is a change-management exercise, not merely a command. A package manager first reads configured repositories and their trust metadata, compares available packages with the local installed-package database, resolves dependency rules, and proposes a transaction. Only after approval should a transaction engine modify package files, scripts, boot artifacts, or service state. Repository signatures authenticate metadata or packages, but they do not prove that an update is operationally compatible with a particular homelab workload.

Inventory is the first control. Record installed package names and versions in a stable format so an administrator can compare the system before and after maintenance. The lab uses two tab-separated fields: package name and installed version. Package families expose this data differently, so blindly assuming every command emits the same format produces unreliable evidence. RPM inventory avoids optional query tags that are absent on older RPM releases, while Alpine inventory is parsed from its local package database because apk info -vv is not a dependable name-and-version TSV interface.

The second control is transaction preview. On APT systems, apt-get --simulate upgrade uses a conservative resolver: installed packages are upgraded when that can be done without removing installed packages. apt-get --simulate dist-upgrade, also known conceptually as a full upgrade, allows dependency resolution that may install additional packages or remove packages. The two previews must therefore be reviewed separately. A removal appearing only in the dist-upgrade plan is not automatically wrong, but it demands an explanation. Kernel, bootloader, libc, database, container runtime, remote-access, storage, and hypervisor packages also deserve explicit maintenance planning because their effects can extend beyond the package transaction.

Simulation output is evidence only when its exit status and errors are retained. An empty-looking plan caused by a package database lock, insufficient privilege, corrupt metadata, or unavailable cache must not be reported as a successful no-op. This lab captures both output streams and records return codes. It does not advise elevating privileges merely to make a preview work; investigate the lock owner or use an approved maintenance window instead.

Batching in this lesson is planning-only. The generated batch plan classifies proposed APT actions into boot or kernel, core libraries, service-impacting packages, and applications or other packages. It does not apply any batch. On a production system, actual grouping must account for dependency constraints, supported intermediate states, redundancy, reboot requirements, snapshots, backups, console access, health checks, and application-owner approval.

Package managers are not universal rollback systems. Downgrades can fail when repositories no longer contain old versions, maintainer scripts are not reversible, databases have migrated, or configuration formats have changed. A safe update plan therefore defines recovery before execution: verify backups, identify a snapshot boundary, preserve configuration, confirm out-of-band access, record package state, establish service checks, and define stop conditions. The final artifacts are checksummed so accidental changes to the review evidence can be detected.