Le 09/05/2021 à 15:18, Allan McRae a écrit :
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
Yes, with this patch, signatures download is under the responsibility of the fetch callback, checking payload->download_signature. That's now implemented in pacman's download_with_xfercommand function.