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