Hide Forgot
The rpm headers define callbacks for RPMCALLBACK_UNINST_PROGRESS, RPMCALLBACK_UNINST_START, and RPMCALLBACK_UNINST_STOP, but the rpm library never issues these callbacks. I have a program whose status reporting could be greatly enhanced if it received callbacks for erased RPMs as well as installed RPMs when running rpmRunTransactions(), and I would greatly appreciate if the library could be enhanced to issue these callbacks. Thank you.
Added RPMCALLBACK_UNINST_* support in rpm-4.0-0.70., will probably be added in rpm-3.0.6 as well. Thanks for pointing out the omission. BTW, can you drop me a note describing what you are doing? Thanks.
RPMCALLBACK_UNINST_PROGRESS seems to have fallen out of fashion in the rpm library when psm.c was created. (I have to admit, I don't quite get the point of psmStage(). It only gets called with a constant "stage" argument, and as far as I can tell it's just a giant switch wrapped around that argument. Normal software engineering would suggest a bunch of different functions. I guess it lets you throw in debugging code in one place.) When there were uninst progress callbacks, "amount" was the number of files left to be removed (so it counted down, not up, which was bizarre) and "total" was a file action, which I guess might be useful in some cases but was nonintuitive and required special handling in the callback. I wouldn't shed any tears if the reborn callbacks used the number of files removed so far for "amount" and the total number of files to be removed for "total." Also, why is there no RPMCALLBACK_INST_STOP? RPMCALLBACK_INST_CLOSE_FILE might suffice, but it doesn't seem like it's quite the same; the file might be closed before scriptlets run, for instance. Sorry to load the bug report with a bunch of tangential questions. The bug report is about the lack of RPMCALLBACK_UNINST_PROGRESS notifications, and can be closed when that is dealt with.
Yup, psmStage() is written as such because a) debugging is trivial b) the single routine and associated data structure are simple to set up as a co-routine, possibly remotely. c) the single entry point eliminates multiple symbols in rpmlib. Otherwise the coding style is obscure and unnecessarily opaque. Call backs on the uninstall path are intrinsically broken, as there is no way in the API to specify the file name and/or python object as there is on the install pathway a la rpmtransAddPackage. What's implemented ATM is pretty sick and evil, relying on a static pointer to a header that is rebound in a lazy fashion on the callback pathway. What's really needed is to rework the callbacks entirely, as the current scheme is good for little more than pushing progress bars, and has rpmlib snarled up with void * that shouldn't be in rpmlib. This will happen (if I have any say, sigh) in rpm-4.1. BTW, I ran across the program you wrote that needed callbacks one time searching around for something else. Could you attach a pointer to the program so I can see what you're trying to accomplish? Thanks.
http://web.mit.edu/source/athena/etc/rpmupdate It's a site-local program I wrote to manage updates of Red Hat machines in our environment (including updates across Red Hat releases) without requiring any user interaction. (I *think* the very gross part at the end is no longer necessary, but I haven't found time to test that.)
FWIW your comments on not exposing enough of the internals (i.e. transactionElement) were part of the motivation to redesign the rpmlib API, thank you. FWIW rpm-4.1 has the following quasi-class structure: transactionSet transactionElement rpmDepSet TFI_t all items headed for exposure with methods. Expect a Grand Unified Renaming somewhen soon ...
Move to FC and create alias
REOPENED status has been deprecated. ASSIGNED with keyword of Reopened is preferred.
User pnasrat@redhat.com's account has been closed
Reassigning to owner after bugzilla made a mess, sorry about the noise...
Implemented upstream, finally. Only took 11.5 years ;) If all goes well, Fedora will get it as of F17.