On 5/5/21 11:54 pm, Guillaume Benoit wrote: > Le 04/05/2021 à 01:30, Allan McRae a écrit : >> On 3/5/21 9:28 pm, Guillaume Benoit wrote: >>> >>> If I have time to work on another version of a patch that pass the full >>> payload to >>> the front-end, is there a chance that it could be included in pacman >>> 6.0 ? >> >> There is a chance... >> >> The things going against me accepting it for 6.0 are I have called a >> freeze apart from already submitted patches and regressions. This is >> not a regression. I guess there will also be an API change. >> >> However, I am slow at reviewing the last patches I need to apply, so a >> patch that appears soon and I judge as having minimal risk for the >> internal download may be accepted. >> >> Allan >> > > v2: I choosed to create another alpm_download_payload struct to only expose > required fields to the API, alpm_cb_fetch callback now has this struct > as argument. > Those are the only API changes. > I also rewrote the download_with_xfercommand function in pacman code. > What is fixed: > - download from an url with a fetch callback for any front-end > - download from an standard url with pacman with a xfercommand > What is not fixed: > - download from an url, with pacman with an xfercommand, when this url > doesn't > contain the filename like > https://archlinux.org/packages/core/x86_64/pacman/download/ >
Does this also replace: libalpm: download signatures with a fetch callback That was on my list next, but I took a quick skim at this patch and it appears to supersede that patch. Allan
