DEBCONF-APT-PROGRESS(1)

💅 DEBCONF-APT-PROGRESS 💅

okay bestie, so this is the debconf-apt-progress manual page, section 1, from the Debconf crew 🫶. It's the little script that makes package installs look cute with an actual progress bar instead of just... silence. Let's get into it ✨

---

🌸 NAME 🌸

debconf-apt-progress — install packages using debconf to display a progress bar 👑

---

✨ SYNOPSIS ✨

debconf-apt-progress [--] command [args ...]
debconf-apt-progress --config
debconf-apt-progress --start
debconf-apt-progress --from waypoint --to waypoint [--] command [args ...]
debconf-apt-progress --stop

---

💖 DESCRIPTION 💖

So debconf-apt-progress installs packages using debconf to show a progress bar, literally that's its whole thing 💫

The command you hand it should be, like, any command-line apt frontend. But here's the catch, bestie — it must send progress info to the file descriptor that's selected by the "APT::Status-Fd" config option, and it must keep the file descriptors nominated by the "APT::Keep-Fds" config option open when it invokes debconf (whether directly or indirectly), because those file descriptors are gonna be used for the debconf passthrough protocol. No pressure or anything 💀

And like, the arguments you give to that command should generally include -y (for apt-get or aptitude) or something similar, so the apt frontend doesn't stop and prompt you for input mid-glow-up. debconf-apt-progress can't do that part itself because the right argument might be totally different depending on which apt frontend you're using, and it's not gonna guess 🙈

The --start, --stop, --from, and --to options are how you build a progress bar with multiple segments for different stages of installation — but only if the caller is a debconf confmodule. The caller can also mess with the progress bar itself using the debconf protocol if it wants to, no judgment 💅

Now here's the messy part: debconf locks its config database when it starts up, which makes it unfortunately inconvenient to have one debconf instance showing the progress bar while another one is passing through questions from the packages being installed. Ugh, I know. So if you're doing a multiple-segment progress bar, you'll need to eval the output of the --config option before starting the debconf frontend, to work around that whole situation. See "EXAMPLES" in the EXAMPLES section below for the recipe 🍓

---

🎀 OPTIONS 🎀

• --config — prints out the environment variables you need to start up a progress bar frontend. It's giving setup ✨
• --start — starts up a progress bar, running from 0 to 100 by default. Wanna use other endpoints? That's what --from and --to are for, babe.
• --from waypoint — if you use it with --start, the progress bar begins at waypoint instead of 0. Otherwise, it installs packages with their progress bar starting at this "waypoint", and in that case it must be used with --to. Periodt.
• --to waypoint — if you use it with --start, the progress bar ends at waypoint instead of 100. Otherwise, it installs packages with their progress bar ending at this "waypoint", and then it must be used with --from. Non-negotiable 💅
• --stop — stops a running progress bar. Bye bestie 👋
• --no-progress — avoids starting, stopping, or stepping the progress bar. But don't worry, progress messages from apt, media change events, and debconf questions still get passed through to debconf. Nothing gets lost, just no bar 🌈
• --dlwaypoint percentage — tells it what percent of the progress bar to use for downloading packages; the remainder goes to installing them. The default is 15% for downloading and the remaining 85% for installing. Math queen behavior 📐
• --logfile file — sends the normal output from apt to the given file. Very demure, very mindful.
• --logstderr — sends the normal output from apt to stderr instead. And heads up: if you supply neither --logfile nor --logstderr, the normal output from apt just gets discarded. Gone. Poof. 😭
• -- — terminates options. And you will usually need this, because you normally have to give at least the -y argument to the command being run, and without -- that would get interpreted as an option to debconf-apt-progress itself instead. So like, use it. Fr fr 🫶

---

🦋 EXAMPLES 🦋

Install the GNOME desktop and an X window system development environment, all inside a progress bar:

debconf-apt-progress -- aptitude -y install gnome x-window-system-dev

Install the GNOME, KDE, and XFCE desktops within a single progress bar, allocating 45% of the progress bar for each of GNOME and KDE and the remaining 10% for XFCE:

#! /bin/sh
set -e
case $1 in
  '')
    eval "$(debconf-apt-progress --config)"
    "$0" debconf
    ;;
  debconf)
    . /usr/share/debconf/confmodule
    debconf-apt-progress --start
    debconf-apt-progress --from 0 --to 45 -- apt-get -y install gnome
    debconf-apt-progress --from 45 --to 90 -- apt-get -y install kde
    debconf-apt-progress --from 90 --to 100 -- apt-get -y install xfce4
    debconf-apt-progress --stop
    ;;
esac

---

👑 RETURN CODE 👑

The exit code of the specified command is returned — unless the user hit the cancel button on the progress bar. If the cancel button was hit, a value of 30 is returned instead.

But wait, plot twist 😭 — to avoid any ambiguity, if the command itself returned 30, then a value of 3 will be returned. Ik, ik, it's a whole thing.

---

🧚 AUTHORS 🧚

• Colin Watson <cjwatson@debian.org>
• Joey Hess <joeyh@debian.org>

---

and that's the whole page, bestie 💖 This one's from the Debconf source, dated 2026-02-16, and it's DEBCONF-APT-PROGRESS(1) — you're all caught up, go install something cute 🎀🫶✨