A long time ago (November 1998) I was bored one weekend, and
bothered that ucd-snmp was exec'ing "rpm -qa" to populate the HR-MIB.

So I sent a patch upstream to ucd-snmp.

Today, the autoconf hackery necessary to link net-snmp into a rpmdb
is the 2nd hardest API (after openssl) to handle on the wide variety
of platforms on which net-snmp is built. Ick.

About a year ago I added a means to synchronously export installed/ erased package metadata. Quite little is needed to populate the SNMP HR-MIB, which
simply needs the name-version-release.arch and installtime, so the
rpmdb export implementation does not have to do anything other than create 0 length
name-version-release.arch files in a directory (/var/cache/hrmib) and
stamp with the installtime.

The final part of the implementation is sending another net-snmp patch upstream to use opendir(3) and readdir(3). I'm likely to get to this week because I have to plug a memory
leak by upgrading to net-snmp-5.4.1.

The synchronous mechanism to automagically export content from package
install/erase can/will be generalized in the following ways:
   1) support for multiple configurable exports
   2) adding custom query format content, including XML/YAML
   3) handling append only operations, like adding to a log.
   4) generating syslog, and possibly dbus or other rpc, messages.

The reason for automating multiple exports is to remove the need to link
a Berkeley DB through -lrpmdb into applications.

Some of the usage cases for an rpmdb are getting quite complex, like
applets and web servers, and handling rpmdb locking simply cannot
be tolerated, supported, or otherwise discussed rationally with web
mistresses and GUI applet developers. Its easier going forward to
just supply custom content to a designated target location for application
specific purposes.

73 de Jeff
______________________________________________________________________
RPM Package Manager                                    http://rpm5.org
Developer Communication List                        rpm-devel@rpm5.org

Reply via email to