> 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. 

Ah, I see.  Well, nothing else can/should be changing the rpmdb on rpm-ostree 
based systems (see also https://github.com/coreos/rpm-ostree/pull/1789 where 
rpm-ostree will start wrapping `/usr/bin/rpm`).

> 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.

OK that seems fine, then we can not install it in the container image and 
rpm-ostree based systems.

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

A few things.  First, rpm-ostree updates are *offline* (generating a new root) 
by default - so anything listening and responding to these DBus signals would 
be confused because it's not affecting the *current* rpm database but a new one 
it can't see.

Second, and related to that - which exact component would be listening to these 
signals?  Would it be `dnf` or `libdnf`?  I really hope it's not the library 
because then rpm-ostree would be talking to *itself* over DBus which...yeah I 
would like not to have that happen :smile: 

Do we really need DBus for this versus just e.g. having interested processes 
use `inotify()` on the path to the rpmdb's directory, and ensuring that RPM 
does `touch(/path/to/rpmdb)` whenever it makes a change?  This is basically 
what we do for ostree changes.  (And yes in some cases rpm-ostreed does catch 
inotify updates from its own changes but that's kind of intentional and much 
less heavy-weight than talking to oneself over dbus)

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Rpm-maint mailing list

Reply via email to