If you are hitting this problem "Hundreds. Of. Times. A. Day.", then there is a
mismatch between what you are expecting, and what is actually implemented in
RPM.
While I am not responsible (or able to even submit an acceptable patch to
rpm.org, sigh),
I can certainly diagnose your problems, and suggest better/alternative usage
for RPM.
I can also *easily* back port the core fix to the problem reported here,
implemented years ago @rpm5.org:
* when DB_RUNRECOVERY is returned opening a BDB dbenv, then do the recovery by
setting a flag, and repeating the open one time, thereby running recovery.
That takes care of the majority of "automated" problems. Other problems exist
if using NETSNMP+RPM, or if using GDB+RPM, usage cases that RPM rpmdb wasn't
ever really
designed for.
Again, I can easily generate the patch for @rpm.org code: just no patch I
submit from
@rpm5.org will *EVER* be acceptable @rpm.org AFAIK (and there are many public
statements to
that effect from @rpm.org and @redhat.com devels).
--
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/232#issuecomment-308304796
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
