Description of problem: The addInstall() and addReinstall() methods of the ts class allow for specifying user data to be passed to the transaction callback during transaction execution (available via the "key" parameter in the below example). This data is quite useful as it can be used to e.g. match the package being manipulated at the moment the callback is invoked. However, this can't be done for erasures since addErase() doesn't accept such a parameter for user data. The callback's "key" parameter only contains the package's name in this case. Example: def my_callback(reason, amount, total, key, client_data): if reason == rpm.RPMCALLBACK_INST_START: # key is a MyPackage instance pkg = key print('Installing:', str(pkg)) # prints "Installing foo-1.0-3" if reason == rpm.RPMCALLBACK_UNINST_START: # key is a string print('Installing:', key) # prints "Installing foo" ... pkg1 = MyPackage('foo-1.0-3') ts.addInstall(pkg1.header, pkg1, 'i') ts.addErase(str(pkg1)) # no way to pass the pkg1 object ts.run(my_callback, None) It would be useful if the user data parameter could also be passed to addErase(). Chatting with lkardos, he thought this could be done by adding an RPM macro which would enable new behavior so the current RPM users would not be affected. This is a low priority thing since we can work this around by e.g. tracking the currently processed transaction element (which does provide package NEVRA) with the help of the callbacks. Version-Release number of selected component (if applicable): rpm-python-4.13.0-0.rc1.7.fc23.x86_64
Oops, a little correction :) print('Installing:', key) # prints "Installing foo" | v print('Uninstalling:', key) # prints "Uninstalling foo"
I meant something different, I meant that if some macro is defined (e. g. %_return_nevra_in_callback) then NEVRA instead of just name of package will be passed as fourth argument (key in your example) to callback function (my_callback in your example). Then you don't need that hack with putting a header object as the first parameter of addInstall().
So the workaround mentioned in Comment 0 actually turns out to be good enough (we can fix bug 1253120) so I'm closing this. (We can always reopen if the workaround turns out to be insufficient.) Thanks Lubos for the assistance, btw.