Hi On Thu, Mar 11, 2021 at 8:15 PM Andrew Gregory <andrew.gregory.8@gmail.com> wrote:
On 03/07/21 at 08:48pm, Anatol Pomozov wrote:
Total download callback called right before packages start downloaded. But we already have an event for such event (ALPM_EVENT_PKG_RETRIEVE_START) and it is naturally to use the event to pass information about expected download size.
Signed-off-by: Anatol Pomozov <anatol.pomozov@gmail.com> ---
WRT this specific patch, it looks like we should do the same for packages downloaded with -U. We weren't calling totaldcb for that before and we won't have a size to pass, but we can still at least pass the count.
Sure, it sounds reasonable to me. We already report this event and all we need to do is to set the number of packages.
At a higher level though, I would like to start providing front-ends the full list of payload data. The existing setup, and this patch, just provide enough information for pacman's display. I think something like the following callback API would be ideal:
/* all_progress - list of all payloads in the transaction * changed - payloads changed since the last cb call * ctx - caller-defined context */ int dlprogresscb(alpm_list_t *all_progress, alpm_list_t *changed, void *ctx)
I think we should split the current payload structure into a download structure and a progress structure. The full list of download structures can then be passed to the fetchcb (and event cb), allowing it to behave much more intelligently than it can now. The list given to the progress callback would be the list of progress structures, which would probably then have a pointer back to the underlying download structure.