[Rpm-maint] [rpm-software-management/rpm] Add rpmtsAddEraseElement2 to API, extend rpmtsAddEraseElement with key data (#1360)

Jaroslav Rohel notifications at github.com
Fri Sep 18 10:37:22 UTC 2020

> The key is not arbitrary "user data", the purpose of the key argument is to allow install callback to locate and open the associated package file and is used and passed around for this very purpose in rpm. There's no counterpart for opening an erasure element because this doesn't seem meaningful.

>From my point of view as a user of the rpm library, the "key" is a pointer to generic user data (arbitrary, a pointer to a void), which I pass to the library and it returns to me in callbacks. I need it to pair the callback with the original transaction element. Specifying an associated package to install is just one reason. I also need to pair during erase surgery. I know purpose for using this argument in rpm. But do all programs have to use this pointer to void by the same way? I think, for rpm library it's just a pointer.

> Any implicitly added erasures (for upgrades and obsoletes) would still not have a key

Yes. I know. But we have prepared transaction with all elements explicitly added. And we need pair callbacks with these elements.

> I can see a need for carrying "user data" in rpmte, but the key has a very specific meaning in rpm and overloading this to other purposes is not likely to end well.
> Thinking about this, I think a more constructive approach would be adding a separate, truly private userdata member to transaction elements and an optional transaction set callback which gets called whenever something changes in the transaction set, which can be used for setting userdata on both explicitly and implicitly added elements (and whatever other purposes, such as easily locate the newly added rpmte element) and doesn't require ugly foo2() functions (or API breakage).

I'm glad you see the need to transfer "user data". If you add a new better API I will be happy. But until then, at least this small improvement to the old API will help us.
I don't want to break the existing API. So, I was just looking for a way to get a user pointer into erase element in the existing API with minimal code changes and without breaking it. And I introduce new API function.
The name of the new function is ugly ... that is why I wrote note: "better API function name name than rpmtsAddEraseElement2 ?"
Can you suggest a better one?

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20200918/ed1c92c1/attachment-0001.html>

More information about the Rpm-maint mailing list