Wrap apt Installs with debconf-apt-progress

Run apt behind debconf-apt-progress and you get a progress bar debconf can drive, plus an exit status that actually reflects what happened. The installed command here comes from Debian's debconf package, version 1.5.86ubuntu1. Allow about fifteen minutes for a simulation, longer if this is a real change going into a maintenance window.

1. Check the installed command

Ordinary, read-only checks:

$ command -v debconf-apt-progress
/usr/bin/debconf-apt-progress
$ dpkg-query -W -f='${Package} ${Version}\n' debconf
debconf 1.5.86ubuntu1

Checkpoint: the command sits at /usr/bin/debconf-apt-progress, and this version is worth recording if it is going into a script or runbook.

Common trap: debconf-apt-progress --help is not an option check on this release. The installed program answers with Unknown option: help; the documented interface lives in the manual page and the forms below.

2. Run a harmless simulation

Put -- before the apt command so the wrapper's own options stop there, leaving -s and -y to apt-get. Add --logstderr while testing so apt's normal output stays visible:

$ debconf-apt-progress --no-progress --logstderr -- apt-get -s -y install debconf
NOTE: This is only a simulation!
debconf is already the newest version (1.5.86ubuntu1).
0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.

Your package summary will differ. What matters is a zero exit status and an apt simulation confirming nothing changed. --no-progress drops the progress bar while keeping the debconf pass-through behaviour, which makes this a predictable thing to test against.

For a real operation, drop -s and use the action you have already reviewed:

$ sudo debconf-apt-progress --logstderr -- apt-get -y install PACKAGE_NAME

Warning: replace PACKAGE_NAME with a package you have actually vetted. This needs sudo because apt is about to modify the package database and installed files, so never paste in an unreviewed name or a shell expression here. If the change touches a running service, line up a rollback and a maintenance window first.

3. Decide where apt output goes

Skip both output options and the wrapper simply throws apt's normal output away. The progress display and debconf questions are a separate channel, so silence is not the same as success. Pick a destination on purpose:

$ debconf-apt-progress --logfile /tmp/apt-progress.log -- apt-get -s -y install debconf
$ sed -n '1,40p' /tmp/apt-progress.log
NOTE: This is only a simulation!

A file under /tmp suits a quick test, not a durable change record. If it captures package or repository detail, treat it as operational data and clear it under your normal retention rules.

4. Preserve and interpret the exit status

The wrapper normally passes through the exit code of whatever it ran, so capture it immediately, before anything else has a chance to overwrite $?:

debconf-apt-progress --no-progress --logstderr -- apt-get -s -y install debconf
status=$?
if [ "$status" -eq 0 ]; then
    printf '%s\n' 'apt simulation succeeded'
else
    printf 'apt command failed with status %s\n' "$status" >&2
    exit "$status"
fi

One special case is worth knowing: press the progress bar's cancel button and debconf-apt-progress returns 30. If the wrapped command itself happens to return 30, the wrapper reports 3 instead, precisely so the two cannot be confused. Treat any other non-zero value as a failed apt run, unless the wrapped command documents something different on purpose.

Recovery: do not turn a failed real install straight into a second unattended attempt. Read what was captured, check apt's actual package state, and only then decide whether resuming is safe. The wrapper provides no undo for packages apt has already changed.

5. Split a larger installation into progress segments

--start, --from, --to, and --stop are for a caller that is already a debconf confmodule, letting several apt commands share one progress bar. Initialise the environment --config prints before starting the frontend:

$ eval "$(debconf-apt-progress --config)"
$ printf '%s\n' "$DEBCONF_DB_REPLACE"
configdb

eval is safe here only because the input comes from the installed command you just ran yourself; never feed arbitrary command output into eval. This particular output sets the debconf database variables that stop two debconf instances fighting over the same lock.

A small shell driver can then hand out 45 percent to each of two stages and 10 percent to the last:

#!/bin/sh
set -e
. /usr/share/debconf/confmodule

debconf-apt-progress --start
debconf-apt-progress --from 0 --to 45 -- apt-get -y install PACKAGE_A
debconf-apt-progress --from 45 --to 90 -- apt-get -y install PACKAGE_B
debconf-apt-progress --from 90 --to 100 -- apt-get -y install PACKAGE_C
debconf-apt-progress --stop

Warning: this script is intentionally a real-change example. Run it only after testing the exact package set with apt-get -s, and as root or through a carefully designed privileged wrapper. set -e stops the script on a failed stage but does not reverse anything that already ran; check the package manager's state before deciding whether to rerun or repair what is left.

6. Adjust the bar without changing apt

Downloads get 15 percent of the bar by default, installation the remaining 85. Change that split with --dlwaypoint when your downloads run unusually large or small:

$ debconf-apt-progress --no-progress --dlwaypoint 30 --logstderr -- apt-get -s -y install debconf

This only changes the progress calculation. It has no effect on apt's download order, package selection, or permissions, and neither do --from and --to: they just move a segment's position in a shared bar, and make nothing about the underlying package operation safer.

Done means