[pacman-dev] [PATCH v2] Remove "total download" callback in favor of generic event callback

Anatol Pomozov anatol.pomozov at gmail.com
Mon Mar 15 23:34:12 UTC 2021


Hi

On Thu, Mar 11, 2021 at 8:15 PM Andrew Gregory
<andrew.gregory.8 at 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 at 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.


More information about the pacman-dev mailing list