Closed #1249 via #1255.
--
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/issues/1249#event-5148416356___
Rpm-maint mailing list
Rpm-mai
Yes I realize DBUS API is an entirely different thing. The reason for bringing
it up here is to think forward in terms of the names used etc - eg
org.rpm.Transaction is something I could imagine wanting to use in such an API,
rpm.org.announce probably not.
--
You are receiving this because you
Well, DBus is not the same as DBus. There are two things you can do there:
This thing here is just sending signals. They go to the bus and are then
relayed to everyone subscribing to them. I don't know that much about DBus but
I would hope sending a few thousands signals shouldn't hurt anyone. By
On a side-note, this whole thing once again makes me think that we really
should have a proper DBUS API for rpm. Yet another thing we should've had ten
years ago already.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
http
Yup, thinking this some more, we don't want to spam the bus with stuff that
most likely nobody will care about.
There probably are some things we can announce (beginning and end of
transactions maybe) but IIRC/AIUI for most part dbus should be about
subscriptions. My memories on this front are r
Question here is what to actually send over the bus. For the initial use case
just announcing the end of a transaction is enough. This allows long running
processes to clue in on other tools changing the rpmdb. But there is obviously
more that could be done: Announcing the start of a transaction
See https://bugzilla.redhat.com/show_bug.cgi?id=1816123 for initial request.
Using DBus would allow pushing even more information like what packages got
installed/removed etc.
This will be based on DBus signals as we (obviously) won't turn RPM into a
daemon. During the transaction signals are g
