[pacman-dev] Fetch callback patch, take 2
Hello people, Here goes another chapter of the fetch callback saga. I finally managed to get a patch working on my copy and completed the integration with Shaman. I have attached a patch that is almost completely based upon Sebastian's one, however it does not abstract the logic of xfercommand out to pacman. Now alpm works this way: 1. If the frontend registered a fetch callback, use that 2. If there is a xfercommand, use that 3. If there's nothing, usual behavior You can pull aqpm+shaman master and check out how things work well. In the shaman land, now it works like this. 1. Shaman creates the queue and streams it to Aqpm 2. Aqpm authentifies itself through Policykit 3. Aqpm spawns an helper, running as root (remember that shaman now doesn't run as root or suid) 4. The helper checks for the caller's authorization, and then registers its own callback. It will then stream progress back to Aqpm through DBus In case the patch doesn't cut out, I was thinking about shipping along with Aqpm a bundled alpm with this patch in, and I would appreciate some opinions on that too. -- ------------------- Dario Freddi KDE Developer GPG Key Signature: 511A9A3B
Somehow the patch didn't make it, I'm pasting it here below: diff --git a/lib/libalpm/alpm.h b/lib/libalpm/alpm.h index 57ea880..363ceee 100644 --- a/lib/libalpm/alpm.h +++ b/lib/libalpm/alpm.h @@ -82,6 +82,17 @@ int alpm_logaction(char *fmt, ...); typedef void (*alpm_cb_download)(const char *filename, off_t xfered, off_t total); typedef void (*alpm_cb_totaldl)(off_t total); +/** A callback for downloading files + * @param url the URL of the file to be downloaded + * @param localpath the directory to which the file should be downloaded + * @param mtimeold the modification time of the file previously downloaded + * @param mtimenew the modification time of the newly downloaded file. + * This should be set by the callback. + * @return 0 on success, 1 if the modification times are identical, -1 on + * error. + */ +typedef int (*alpm_cb_fetch)(const char *url, const char *localpath, + time_t mtimeold, time_t *mtimenew); /* * Options @@ -93,6 +104,9 @@ void alpm_option_set_logcb(alpm_cb_log cb); alpm_cb_download alpm_option_get_dlcb(); void alpm_option_set_dlcb(alpm_cb_download cb); +alpm_cb_fetch alpm_option_get_fetchcb(); +void alpm_option_set_fetchcb(alpm_cb_fetch cb); + alpm_cb_totaldl alpm_option_get_totaldlcb(); void alpm_option_set_totaldlcb(alpm_cb_totaldl cb); diff --git a/lib/libalpm/dload.c b/lib/libalpm/dload.c index 5b0a691..c0c9bf7 100644 --- a/lib/libalpm/dload.c +++ b/lib/libalpm/dload.c @@ -352,12 +352,15 @@ static int download(const char *url, const char *localpath, int ret; /* We have a few things to take into account here. - * 1. If we have both internal/external available, choose based on + * 1. If we have a fetch callback, use it + * 2. If we have both internal/external available, choose based on * whether xfercommand is populated. - * 2. If we only have external available, we should first check + * 3. If we only have external available, we should first check * if a command was provided before we drop into download_external. */ - if(handle->xfercommand == NULL) { + if(handle->fetchcb != NULL) { + return handle->fetchcb(url, localpath, mtimeold, mtimenew); + } else if(handle->xfercommand == NULL) { #if defined(INTERNAL_DOWNLOAD) ret = download_internal(url, localpath, mtimeold, mtimenew); #else diff --git a/lib/libalpm/handle.c b/lib/libalpm/handle.c index 813f439..48edab8 100644 --- a/lib/libalpm/handle.c +++ b/lib/libalpm/handle.c @@ -105,6 +105,15 @@ alpm_cb_download SYMEXPORT alpm_option_get_dlcb() return handle->dlcb; } +alpm_cb_fetch SYMEXPORT alpm_option_get_fetchcb() +{ + if (handle == NULL) { + pm_errno = PM_ERR_HANDLE_NULL; + return NULL; + } + return handle->fetchcb; +} + alpm_cb_totaldl SYMEXPORT alpm_option_get_totaldlcb() { if (handle == NULL) { @@ -258,6 +267,15 @@ void SYMEXPORT alpm_option_set_dlcb(alpm_cb_download cb) handle->dlcb = cb; } +void SYMEXPORT alpm_option_set_fetchcb(alpm_cb_fetch cb) +{ + if (handle == NULL) { + pm_errno = PM_ERR_HANDLE_NULL; + return; + } + handle->fetchcb = cb; +} + void SYMEXPORT alpm_option_set_totaldlcb(alpm_cb_totaldl cb) { if (handle == NULL) { diff --git a/lib/libalpm/handle.h b/lib/libalpm/handle.h index ad7666d..85aaf55 100644 --- a/lib/libalpm/handle.h +++ b/lib/libalpm/handle.h @@ -39,6 +39,7 @@ typedef struct _pmhandle_t { /* callback functions */ alpm_cb_log logcb; /* Log callback function */ alpm_cb_download dlcb; /* Download callback function */ + alpm_cb_fetch fetchcb; /* Download file callback function */ alpm_cb_totaldl totaldlcb; /* Total download callback function */ /* filesystem paths */ -- ------------------- Dario Freddi KDE Developer GPG Key Signature: 511A9A3B
On Fri, May 29, 2009 at 8:21 PM, Dario Freddi
Hello people,
Here goes another chapter of the fetch callback saga. I finally managed to get a patch working on my copy and completed the integration with Shaman. I have attached a patch that is almost completely based upon Sebastian's one, however it does not abstract the logic of xfercommand out to pacman. Now alpm works this way:
1. If the frontend registered a fetch callback, use that 2. If there is a xfercommand, use that 3. If there's nothing, usual behavior
Do you realize your patch is the first one Xilon submitted : http://www.archlinux.org/pipermail/pacman-dev/2009-February/008198.html Then Aaron made the suggestion to move xfercommand handling to pacman frontend, and to use fetch callback to register it. Why did you revert this change, why is it problematic for you? And why didn't you say anything back then?
In data sabato 18 luglio 2009 12:25:19, Xavier ha scritto:
Do you realize your patch is the first one Xilon submitted : http://www.archlinux.org/pipermail/pacman-dev/2009-February/008198.html
No, I didn't know it, or better I didn't remember of it (and that was a long, long time ago, so I think it's quite understandable)
Then Aaron made the suggestion to move xfercommand handling to pacman frontend, and to use fetch callback to register it. Why did you revert this change, why is it problematic for you? And why didn't you say anything back then?
It's not problematic, I tried to simplify the patch since Sebastian's one seemed not to get in for some reason. I'm completely ok both ways, I think it boils down to personal preferences, I only care about the damn fetch callback getting in. If you prefer having xfercommand handled that way, Sebastian's patch will work more than fine. -- ------------------- Dario Freddi KDE Developer GPG Key Signature: 511A9A3B
participants (2)
-
Dario Freddi
-
Xavier