diff options
author | Anatol Pomozov <anatol.pomozov@gmail.com> | 2020-05-06 04:50:51 +0200 |
---|---|---|
committer | Allan McRae <allan@archlinux.org> | 2020-05-09 03:58:21 +0200 |
commit | c78eb48d915dc22146073162dda08ddf73c4a508 (patch) | |
tree | 9daffa23a059dc690cb2d43a0d234f79932b0dab /lib/libalpm/add.c | |
parent | 64c4669f579dc5ad8d05329abffbd752ad0ed8f2 (diff) | |
download | pacman-c78eb48d915dc22146073162dda08ddf73c4a508.tar.gz pacman-c78eb48d915dc22146073162dda08ddf73c4a508.tar.xz |
Extend download callback interface with start/complete events
With the previous download interface the callback uses the first progress
event as 'download has started' signal. Unfortunately it does not work with
up-to-date files that never receive 'download progress' events.
Up-to-date database messages are currently handled in sync_syncdbs()
after the sequential download is completed and a result from ALPM is
received. But this is not going to work with multiplexed download
interface that returns the result only after all files are completed.
Another problem with 'first progress event is the beginning of the
download' is that such events time are unpredictable. Thus the UI progress
bar order might differ from what has been passed by client to
alpm_dbs_update() function. We actually want to keep the dbs progress bars
in a strict order.
To help to solve the given problems extend the download callback to
allow 2 more events - download started and completed. 'Download started'
events appear in the same order as in the list given by a client.
Signed-off-by: Anatol Pomozov <anatol.pomozov@gmail.com>
Signed-off-by: Allan McRae <allan@archlinux.org>
Diffstat (limited to 'lib/libalpm/add.c')
0 files changed, 0 insertions, 0 deletions