On Aug 13, 2012, at 11:16 AM, Paul Eggleton paul.eggle...@linux.intel.com
wrote:
Hi there,
Following my previous request for assistance with performing rpm db queries
from C with rpm 5.4.9 (thanks for the help with that!), I put together the
following utility:
http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-devtools/rpm/rpmresolve/rpmresolve.c
todo++: will look in a moment.
This consolidates a couple of the operations we used to do with multiple
invocations of rpm, and improved performance of those operations as a
result. I'd definitely appreciate any suggestions for improvements to the
code though as I am still a novice when it comes to using the RPM libraries.
(I could probably be doing better error checking for a few of the calls, I'm
already aware of that.)
However, we are experiencing an intermittent problem apparently now brought
to the surface with this utility - an assertion failure when opening the
database:
| rpmresolve: dbconfig.c:493: db3New: Assertion `dbOpts != ((void *)0)
*dbOpts != '\0'' failed.
This failure (usually) occurs when /usr/lib/rpm/macros wasn't read,
usually because of CLI overrides in a host - target environment.
There's another (possible but unlikely) failure if there
is an access of a non-defined tag used in an index.
Use gdb and see what value is in tag here. Alternatively,
you can wrap
%trace…%trace
(%trace is a toggle) or add
%dump...
(%dump will spew all defined macros) to the specific macro expansion.
Unfortunately the problem does not occur every time and so far we have not
been able to reproduce it outside our build environment; we did however
see this error previously with rpm itself, just not as frequently as we are
now. It seems that it is a result of the dbi_config macro being unset or
otherwise resolving to empty string / null, but as far as I can tell this
macro is set as part of the main rpm macros file so I can't see how it
could not be set. I notice the same assertion failure in the following report
but there was no further information to suggest why it occurred there:
H … dunno why intermittent: this code (and the assert)
is traversed on every table open.
http://marc.info/?l=rpm-develm=126175013622633
There are problem in perl bindings with finding modules:
one MUST install (circa 2009, ~fixed now to run in tree) the CPAN module in
order to run tests.
Issues with bindings are from unusual code paths that
fail to read necessary configuration (for whatever reason).
Does anyone have any clues as to how this failure could come about?
hth
73 de Jeff
Thanks,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
__
RPM Package Managerhttp://rpm5.org
Developer Communication Listrpm-devel@rpm5.org
