Actually, rpmtsInitIterator() is/was an attempt to simplify retrievals by
hiding the DB handle getter within a pass through lookup. Acceptance and
updating code has been glacially slow all century.
Note that rpmdbOpen's calls have had some very peculiar side effects to
accomodate user demands (I'm not sure what the current state of affairs is: I
tend to avoid *all* rpmdb questions in public).
Usually, the rpmdb is opened (and reopened RO -> RW) lazily when needed during
The peculiar side effect I mention is/was -- if the application/user chose to
explicitly open an rpmdb -- then that also disabled all opens.reopens that are
usually handled when/where needed during rpmts handling. The rationale for the
peculiarity is/was solely a principle of least surprise at the time.
There has been too little usage of alternative back ends to understand whether
an explicit DB handle might be useful.
In general however, I believe your rust bindings would be improved by _NOT_
binding rpmdb open/close/init/delete/verify operations: attach methods to a
rpmts object and use the rpmdb attached to a rpmts instead.
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