Bug 16253 (RpmEraseCallback) - Want librpm callbacks for erased RPMs
Summary: Want librpm callbacks for erased RPMs
Status: CLOSED UPSTREAM
Alias: RpmEraseCallback
Product: Fedora
Classification: Fedora
Component: rpm   
(Show other bugs)
Version: rawhide
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Panu Matilainen
QA Contact:
URL:
Whiteboard:
Keywords: FutureFeature, Reopened
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2000-08-15 15:21 UTC by Greg Hudson
Modified: 2012-01-05 14:42 UTC (History)
0 users

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-01-05 14:42:47 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Greg Hudson 2000-08-15 15:21:14 UTC
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.

Comment 1 Jeff Johnson 2000-08-20 07:10:52 UTC
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.

Comment 2 Greg Hudson 2002-05-13 13:54:17 UTC
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.


Comment 3 Jeff Johnson 2002-05-13 14:09:55 UTC
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.
	

Comment 4 Greg Hudson 2002-05-13 14:30:58 UTC
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.)


Comment 5 Jeff Johnson 2002-05-13 15:48:00 UTC
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 ...
			

Comment 6 Paul Nasrat 2005-06-07 19:09:20 UTC
Move to FC and create alias

Comment 7 Red Hat Bugzilla 2007-02-05 19:15:36 UTC
REOPENED status has been deprecated. ASSIGNED with keyword of Reopened is preferred.

Comment 8 Red Hat Bugzilla 2007-08-21 05:16:43 UTC
User pnasrat@redhat.com's account has been closed

Comment 9 Panu Matilainen 2007-08-22 06:35:02 UTC
Reassigning to owner after bugzilla made a mess, sorry about the noise...

Comment 10 Panu Matilainen 2012-01-05 14:42:47 UTC
Implemented upstream, finally. Only took 11.5 years ;)
If all goes well, Fedora will get it as of F17.


Note You need to log in before you can comment on or make changes to this bug.