apk: provide a more reliable way for post-upgrade warnings
Right now packages that want to tell the user about important manual steps can only do so by a post-upgrade warning. This is e.g. being discussed on !58567
This is fragile - users may simply miss the warning among all the other apk output.
Thus I propose some way for packages to warn the user about potentially necessary manual steps, such as (in decreasing order of implementation complexity):
-
A separate apk stage that runs after upgrading and triggers, and is intended to primarily show warnings. It has to come after triggers, as some triggers (e.g. akms) can output many screenfuls and thus hide important warnings.
-
A convention that all "important warnings" output by a post-upgrade script must start with a specific prefix, and a change to apk so it collects those during upgrading and repeats them at the end as a final output.
- So basically, a trivial but very dirty implementation:
#!/bin/sh # apk.sh - apk wrapper that repeats important warnings warnings=$(apk "$@" 2>&1 | tee /dev/stderr | grep ^WARNING:) echo "$warnings"
- So basically, a trivial but very dirty implementation:
-
A convention that package scripts (including triggers) shall not write anything to stdout/stderr unless it is critically important (or at least be limited to a single line of output); other output could go to syslog or similar places instead. On my system this would primarily impact grub's and akms's triggers, which then would no longer print to stdout/stderr, but just write their progress output to syslog. In case of akms it might make sense to have at least a single line of progress that's refreshed but doesn't advance to the next line.
Long-term it could also make sense to have pre-upgrade and pre-install warnings, which apk would (as IIRC there is a policy that apk shall be non-interactive by default) normally just print prior to installing anything, but there could be an apk flag to make them blocking and wait for an enter press. In fact, the existing -i flag of apk could also enable these. Could even also add a flag to apk that fails the upgrade if a preinstall warning exists (that way, adventurous people could run apk upgrade from a cronjob).