On 11/15/13 16:15, Andrew Gregory wrote:
On 11/15/13 at 02:44pm, Olivier Brunel wrote:
On 11/15/13 12:28, Allan McRae wrote:
On 10/11/13 04:49, Olivier Brunel wrote:
Signed-off-by: Olivier Brunel <jjk@jjacky.com> --- Hey,
Some background regarding this: I've written a little tool (kalu, [1]) which is an upgrade notifier, and also features a GUI/frontend for the sysupgrade (-Syu) operation.
Whenever there was a pacnew installed, I would open a terminal and run vimdiff on the files; I would also wonder if it wouldn't be nice to have a third file featured, the "original" one (i.e. from the previous package). And so I started wondering about kalu making a list of all pacnew files created during the upgrade, as well as the name & version of the old package, so that I could use a little script to extract the file and start the 3-way diff.
(kalu allows to execute one or more command lines after the sysupgrade completed, so this list is just a variable parsed on said cmdlines.)
This all works well, but to make that list, kalu would have to e.g. use a regex to extract the pacnew filenames from ALPM's warnings, and that's just not a very good or reliable thing, especially when you know such warnings are translated.
Hence, why adding a couple events (there's pacorig as well) in ALPM makes everything much better & simpler; And knowing about such events could be useful to some frontends, even though pacman obviously has no use for it (atm).
So, I'm hoping you'd be willing to merge this.
Thanks, -j
I agree the backend should report this to the frontend. In fact, I would like the backend to be completely quiet and report everything to the frontend.
Not sure what you mean by "completely quiet" ? When I read that, I took it to mean as far as the log goes (since ALPM doesn't output anything), that you'd like for frontends to be doing all the logging...
But that goes against a recent patch[1] you committed, which does the very opposite, and moved logging from pacman into ALPM. So I'm not sure I understand what you mean here.
The problem is the use of _alpm_log. Even though alpm doesn't actually output the message, it's passing a translated string to the frontend which can't decipher or act on it. The frontend effectively acts as a simple middle-man for alpm's output. pacman should be printing the output from the event callback, allowing it to translate/colorize/etc the output.
Oh, so the goal would be to have ALPM do the logging, but let the frontend print something to the user based on the event instead of just relaying whatever was logged. How would that work? If ALPM both triggers the event and still writes to the log, and also triggers the log callback, the frontend has no way of knowing when to ignore certain log messages (because an event was/will be triggered for it) and when not to. So it would then require to remove the log callback, leaving the log handled (quietly, I get it now ;)) by ALPM, but making sure everything that's logged has a corresponding event, specifically we'd need a SCRIPTLET_OUTOUT event of some kind, as well as events for warnings/errors/debug messages. Would that be right?
Lets look at what your patch currently does:
alpm_pkg_t *arr[2] = { oldpkg, newpkg }; EVENT(handle, ALPM_EVENT_PACNEW, arr, newpath);
First the passed path. I think passing filename (e.g. /etc/pacman.conf) rather than newpath (e.g. /etc/pacman.conf.pacsave) is the better approach for that. It requires less to output a ".pacsave" than to remove one.
Agreed.
Now I am not sure about the oldpkg/newpkg in an array passing. I think just passing pkgname is a reasonable compromise. I guess the frontend then can grab the old package version easily enough.
Well, the reason I did this was that - as explained - I wanted to have the old version, but it makes sense to also have the new one (plus, I felt it was also better for consistency w/ pacsave files).
This was a simple way to make sure the frontend has all correct info. Otherwise, the frontend needs to store that event somewhere, then wait for the next UPGRADE_DONE event to assign the version number(s) to all "unassigned/versionless" pacnew/pacsave files. It just doesn't feel as good/reliable.
I could have just put oldpkg, newpkg being easy enough to get if one needs to, since it should be the currently installed one, but then pacnew would have had oldpkg, and pacsave newpkg (since there's no oldpkg), which I thought might not be the best re: consistency. Although, since both don't have the same arguments either way, I'm not sure there's consistency if any case actually.
If you're against the array passing, I'd like to use oldpkg for pacnew & newpkg for pacsave better than just passing the pkgname.
At the time of extraction oldpkg has already been removed from the local package cache and newpkg hasn't been added yet, so I don't think there is any reliable way to get at either of them unless they are passed directly to the callback.
How about switching from a (void*, void*) callback to an event_context_t struct? We could pass as much information to the callback as we need and give everything proper names and types. Alternatively, we could pass an alpm_list_t so that we're at least not arbitrarily limited to two arguments. A list with mixed types is ugly, but shouldn't be too horrible as long as the backend takes care of freeing everything that needs it.
You mean change the event callback signature ? Well, that's a(nother) major API break then; And I guess it's not for the scope of this patch. This is about adding events for pac* files, there should be another patch changing the event callback signature & removing the log callback, as described above. If that were to happen though, I'm not sure I see much improvement over the current solution in using an event_context_t struct, I mean there can't be one type that fits all events nor can everything to be needed in the future be thought of ahead of time, so it doesn't seem ideal to me. A list allows more than 2 arguments, but really you just need one, e.g. an event_t union, to be a different struct based on the actual event. If you know a bit about GTK, similar to how they have GdkEvent an union of GkEventButton, GdkEventKey, etc Wouldn't that be simpler? (Or what that what you meant already?) -j
lib/libalpm/add.c | 3 +++ lib/libalpm/alpm.h | 10 +++++++++- src/pacman/callback.c | 3 +++ 3 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/lib/libalpm/add.c b/lib/libalpm/add.c index ac4e36a..e5eca97 100644 --- a/lib/libalpm/add.c +++ b/lib/libalpm/add.c @@ -363,10 +363,12 @@ static int extract_single_file(alpm_handle_t *handle, struct archive *archive, if(try_rename(handle, checkfile, newpath)) { errors++; } else { + alpm_pkg_t *arr[2] = { oldpkg, newpkg }; _alpm_log(handle, ALPM_LOG_WARNING, _("%s installed as %s\n"), filename, newpath); alpm_logaction(handle, ALPM_CALLER_PREFIX, "warning: %s installed as %s\n", filename, newpath); + EVENT(handle, ALPM_EVENT_PACNEW, arr, newpath); }
free(newpath); @@ -395,6 +397,7 @@ static int extract_single_file(alpm_handle_t *handle, struct archive *archive, _("%s saved as %s\n"), filename, newpath); alpm_logaction(handle, ALPM_CALLER_PREFIX, "warning: %s saved as %s\n", filename, newpath); + EVENT(handle, ALPM_EVENT_PACORIG, newpkg, newpath); } }
diff --git a/lib/libalpm/alpm.h b/lib/libalpm/alpm.h index 2c8c1e6..c4f772d 100644 --- a/lib/libalpm/alpm.h +++ b/lib/libalpm/alpm.h @@ -387,7 +387,15 @@ typedef enum _alpm_event_t { /** Downloading missing keys into keyring. */ ALPM_EVENT_KEY_DOWNLOAD_START, /** Key downloading is finished. */ - ALPM_EVENT_KEY_DOWNLOAD_DONE + ALPM_EVENT_KEY_DOWNLOAD_DONE, + /** A .pacnew file was installed + * An array of packages (current/old one, and installed/new one) and the + * name of the pacnew file are passed to the callback */ + ALPM_EVENT_PACNEW, + /** A .pacorig file was created + * The installed/new package and the name of the pacorig file are passed to + * the callback */ + ALPM_EVENT_PACORIG
Rename these ALPM_EVENT_*_CREATED or something similar so they match up with the other event names a little better and to avoid confusion if we ever add any other pacnew/pacorig related events. We should also add a similar event for pacsave files for consistency.
} alpm_event_t;
/** Event callback */ diff --git a/src/pacman/callback.c b/src/pacman/callback.c index 36531a2..0fc35f6 100644 --- a/src/pacman/callback.c +++ b/src/pacman/callback.c @@ -297,6 +297,9 @@ void cb_event(alpm_event_t event, void *data1, void *data2) case ALPM_EVENT_DELTA_INTEGRITY_DONE: case ALPM_EVENT_DELTA_PATCHES_DONE: case ALPM_EVENT_DISKSPACE_DONE: + /* events of creation of .pacnew/.pacorig files */ + case ALPM_EVENT_PACNEW: + case ALPM_EVENT_PACORIG:
This is where "foo installed as bar" needs to be printed. Then we can easily implement FS#37711.
/* nothing */ break; }