A Long Time Ago there were demands for rpmlib to report its
state better. Those demands remain to this day ...

Since whatever "state" is passed through the callback, the means by  
which rpmlib
communicates with the script kiddie applications, the choice of what  
is "state"
is unfortunately locked into an interface through complicated overloaded
integers that already don't have enough bits to pass information  
which is
_ALREADY_ implemented in rpmlib.

Back in the days of yore, there used to be something called a  
"string". That
data structure, if used with discipline, with conventions about  
values, is a
perfectly wonderful data object for communicating information about  
"state".

So rpmlog() was added to accumulate strings about "state" that might  
reasonably
be passed to applications that are curious about what rpmlib is  
actually doing.

In order to maintain a pretense of API/ABI compatibility for the 3-5  
programs that
have ever linked rpmlib, just oin case some naive programmer wanted  
to actually
use rpmlib's internal error mechanism, both rpmError and rpmMessage were
re-implemented on top of rpmlog.

There are (at least) several problems with continuing to use rpmError 
() and rpmMessage(),
not the least of which, is that there are the usual syslog(3) like  
side effects, one of which
is i8mmedfiate exit.

Another side effect is that there are manifest constatnts (see  
rpmconstant) that look
like they are useful and/or meaningful. I refer to RPMERR_FOO ...

All of this gook needs to be abandoned in favor of "strings", not rpm- 
lua bindings, not
Yet More means to populate applications with "stuff" that is poorly  
designed and worse.

And the callback needs to be abandoned, not the least of which, is  
that there is no
current means for the script kiddie applications to actually pass  
information _BACK_
to rpmlib, where reasonable efforts, like closing an rpmdb, might  
actually be attempted.

73 de Jeff