Problem
An Apply runs apt-get upgrade, which by design keeps back any Patch that would require installing or removing other packages. In practice this is kernel meta-packages (linux-aws, linux-image-aws, linux-headers-aws).
Observed on hermes: Apply All succeeded (exit 0) but the output ended with:
The following packages have been kept back:
linux-aws linux-headers-aws linux-image-aws
0 upgraded, 0 newly installed, 0 to remove and 3 not upgraded.
A follow-up Scan correctly still reports 3 Patches. The count never clears, which reads as a bug but is correct apt behavior.
Domain framing (resolved, see CONTEXT.md)
These 3 are still Patches. "Kept back" is not a property of the Patch — it is the boundary of the current Apply's reachable scope. The real question is whether we want a fuller Apply, not a new noun.
Options
- Surface why (no apt change). Detect "kept back" lines in Apply output and show a note in the UI ("N packages need a kernel upgrade + reboot") so the lingering count isn't confusing. Lowest risk.
- Separate dist-upgrade action. Keep Apply All as
upgrade; add an explicit, clearly-labeled "Full upgrade" action that runs apt-get dist-upgrade. Opt-in, more invasive, usually needs a reboot.
- Switch Apply All to dist-upgrade. Simplest count-clearing, but can add/remove packages and needs a reboot — surprising for a one-click action.
Likely also in scope: check /var/run/reboot-required after an Apply and surface a "reboot needed" state; consider distinguishing security vs. regular updates (the apt security pocket).
Prior art: Coolify
Coolify's "Server Patching" runs the same apt update && apt upgrade -y (app/Actions/Server/UpdatePackage.php) and has the exact same gap — kept-back kernels are surfaced but never applied, no dist-upgrade, no reboot detection. Their "critical packages may require restarts" Discord line is a substring match on package name for docker/kernel/openssh/ssl — and notably would not even flag Ubuntu's linux-* packages (no "kernel" substring). So this is a differentiation opportunity, not a catch-up.
Notes
- Decision deferred deliberately; current behavior (
upgrade, safe) is correct and matches Coolify.
- If we add
dist-upgrade, it crosses an architectural line (a second kind of Apply + reboot handling) — write an ADR.
Problem
An Apply runs
apt-get upgrade, which by design keeps back any Patch that would require installing or removing other packages. In practice this is kernel meta-packages (linux-aws,linux-image-aws,linux-headers-aws).Observed on
hermes: Apply All succeeded (exit 0) but the output ended with:A follow-up Scan correctly still reports 3 Patches. The count never clears, which reads as a bug but is correct apt behavior.
Domain framing (resolved, see CONTEXT.md)
These 3 are still Patches. "Kept back" is not a property of the Patch — it is the boundary of the current Apply's reachable scope. The real question is whether we want a fuller Apply, not a new noun.
Options
upgrade; add an explicit, clearly-labeled "Full upgrade" action that runsapt-get dist-upgrade. Opt-in, more invasive, usually needs a reboot.Likely also in scope: check
/var/run/reboot-requiredafter an Apply and surface a "reboot needed" state; consider distinguishing security vs. regular updates (the apt security pocket).Prior art: Coolify
Coolify's "Server Patching" runs the same
apt update && apt upgrade -y(app/Actions/Server/UpdatePackage.php) and has the exact same gap — kept-back kernels are surfaced but never applied, nodist-upgrade, no reboot detection. Their "critical packages may require restarts" Discord line is a substring match on package name fordocker/kernel/openssh/ssl— and notably would not even flag Ubuntu'slinux-*packages (no "kernel" substring). So this is a differentiation opportunity, not a catch-up.Notes
upgrade, safe) is correct and matches Coolify.dist-upgrade, it crosses an architectural line (a second kind of Apply + reboot handling) — write an ADR.