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.
