> Is there any coordination between this and the work to add dbus to libdnf in 
> [rpm-software-management/libdnf#941](https://github.com/rpm-software-management/libdnf/pull/941)
>  for example?

Well, we add this on request of the DNF team that need to be notified if 
something else (rpm cli) changes the rpmdb underneath their daemon. Note that 
this is very different from the lib dnf thing even if it also uses DBus. RPM 
will not offer a DBUS interface that can be queried or send commands to. All 
this does is sending out signals that notify who ever is interested that the 
rpmdb is changing.
I will probably even drop the second patch providing more detailed information 
until there are real use cases. So all this is going to do is sending out a 
ping at the start and the end of every transaction.

> For rpm-ostree we are already a DBus daemon, and having multiple other 
> libraries in the stack also going out and talking to DBus is going to be a 
> bit problematic.
> Binding this to the systemd-inhibit plugin makes sense because we already 
> turn that off for rpm-ostree (because it's transactional, there's no reason 
> to inhibit).

So this is going to be a plugin that can be disabled or just plainly not be 
installed in the first place. We will probably not integrate this into the 
systemd-inhibit plugin but have it as a separate plugin that is very similar 
and comes in it's own sub package.

Can you please elaborate on why sending some DBus signals should be problematic?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1255#issuecomment-641112150
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Reply via email to