Hi On Thu, Mar 11, 2021 at 8:15 PM Andrew Gregory <[email protected]> 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 <[email protected]> > > --- > > 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.
