Move the bar while packages are downloading

The progress entry sat at "0 von 123" for the whole download and only
started counting once pacman began unpacking - which on a domestic line is
most of the run spent looking like nothing was happening. What was being
watched for was the transaction, and the transaction had not started yet.

Downloading is now a step of its own, worth 30 of the bar against the
transaction's 40, counted the same way: one line per package out of
pacman's "foo-1.2-1-x86_64 downloading...". The database sync just before
it prints the identical shape with the suffix that would give it away
already stripped, so the tally starts only after the ":: Retrieving
packages..." header. Packages already in the cache never announce
themselves, so the step regularly ends short of its total and hands the
rest of its share over when unpacking begins.

The headline follows: "Updates werden heruntergeladen", then
"Systempakete werden aktualisiert".
This commit is contained in:
Felitendo committed 2026-08-14 14:22:05 +02:00
1 parent 6538c1510d
commit b796b2711a
7 files changed
+90 -18

No files matched your search

+12 -4
View File
@@ -122,10 +122,18 @@ of the update and holds that connection open. It requires _python-gobject_.
Where that is missing, or on a desktop with no job interface, there is no
progress entry and nothing else is affected.
The position within the repository step is read from pacman's own
"(120/260) upgrading foo" output. Its other (n/m) sequences - checking keys,
package integrity, loading package files - each count up to the same total and
are deliberately ignored.
Fetching the packages and unpacking them are two steps rather than one. On a
domestic line the download is the longer of the two, and a bar that called the
whole thing "installing" would sit near its beginning for minutes at a time
looking stuck.
Neither phase gets a counter from pacman on an unattended run, so both are
counted here, a line at a time: "foo-1.2-1-x86_64 downloading..." for the
first, "upgrading foo..." for the second. Packages already in the cache are
never announced, so the download step regularly ends short of its total and
gives up the rest of its share when unpacking begins. pacman's other (n/m)
sequences - checking keys, package integrity, loading package files - each
count up to the same total and are deliberately ignored.
# HOW LONG NOTIFICATIONS STAY