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 
rpmts processing.

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:
https://github.com/rpm-software-management/rpm/issues/429#issuecomment-381230556
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Reply via email to