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.