[Rpm-maint] [rpm-software-management/rpm] Add dbus-announce plugin (#1255)

[Panu Matilainen]

> > imposes its own signal handling on users when the db is open
> 
> Can turn that off since [56f49d7](https://github.com/rpm-software-management/rpm/commit/56f49d7f5af7c1c8a3eb478431356195adbfdd25) right?

API users turning off signal handling is not a solution, it's a problem in its own right.

> > and our ABI hasn't been particularly stable historically
> 
> Maintaining C shared libraries is indeed extremely hard. I've messed up in the past and only just barely caught it before releases etc. That said there are nice tools now like [libabigail](https://pagure.io/libabigail) - should be easy to set that up on CI here right?
> (I still need to do that for ostree)

librpm ABI stability or lack of thereof has little to do about it being difficult, it's merely that rpm has historically exported all manner of crap that it never should have, and it's not possible to get rid off it all in one go, unfortunately. So for 12+ years we've done staged "exit accumulated crap, bump soname" releases every now and then, rpm soname bumps are an absolute PITA.

> > dbus library itself is much more stable AIUI.
> 
> Yeah, libdbus as a C shared library has been fine and will continue to be so, but exposing an API over DBus is a separate thing with long term commitments.

Eh, no kidding?

> 
> If we're effectively saying most projects shouldn't be using librpm to read the rpm database effectively (that seems like what you're implying) that's a rather radical thing right? Maybe I am misunderstanding though.

I said no such thing. Different users have different priorities and needs, projects should (be able to) use what works best for them. 

Linking to librpm comes with heavy and hard to understand babbage and is way too intimate (think "bare metal") for various "casual" users. A DBus API puts a much needed insulation layer between the process that actually accesses rpmdb and the unsuspecting piece of software wanting to know something about packages on the system. With the existing librpm API, very weird things happen in dark corners such as gdb running as root on a 32bit process on a 64bit system, doing rpmdb query for debuginfo discovery.

-- 
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-650015111
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20200626/5e360187/attachment.html>