> This isn't just for dnf's benefit. It's a mechanism that anybody who needs to 
> do so is free to listen, and everybody else can ignore.

Speaking as a former DBus maintainer upstream here and I have written many DBus 

It seems dramatically simpler to me to go with the inotify approach, the 
requirement is basically for librpm to `touch` the toplevel directory of the 
database path.  It's near zero cost if there is nothing listening.

And most crucially it avoids creating a new API for things to try to 
query/monitor the rpm database state.  There's already an API for that via 
librpm.  This signal isn't extensible - if e.g. a new field (say something 
related to modules) becomes interesting then we'd have to define a new one.  
Handling that requires going down to a "bag of properties" i.e. `a{sv}` in DBus 
type code model.  (We do this in many places in rpm-ostree) - but it loses some 
of the elegance.

A DBus API is a serious commitment, particularly once you have things listening 
to it.

That said a particular strength of DBus (really the reason it was created) is 
to be able to to cross privilege boundaries by having unprivileged processes 
(originally the desktop) sanely monitor and interact with system services.  But 
in this case since the consumer is (theoretically) dnf they're in the same 
privilege level (and in fact the same process!), so that doesn't apply.

FWIW here's the libostree code to bump mtime: 

And here's where rpm-ostree uses it: 

That's how rpm-ostreed gets notified if e.g. an admin directly runs `ostree 
admin <foo>`, which is a lot like the situation where someone is using a 
traditional rpm system with a DBus daemon like dnfdragora/PackageKit or 
whatever and an admin uses `rpm -ivh` or so.

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