> > 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
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
