RPM Community Forums

Mailing List Message of <rpm-devel>

Re: Unsnarling an rpmdb from the HR MIB

From: Jeff Johnson <n3npq@mac.com>
Date: Fri 05 Sep 2008 - 20:13:56 CEST
Message-id: <7E751910-2744-4819-969D-14C31B3B9DAE@mac.com>
Dave --

Apologies for the delay. I set out to do this patch and instantly
got hit with an RFE to rearrange RPM's API so that all include
files are "standalone", i.e. any/all files can be included without  
any other
prerequisite includes.

Makes it kinda hard to do a patch for an API that is changing ...

Meanwhile, the attached patch, when used with


achieves  compilation of net-snmp-5.4 using rpm-5.1.4.

These are the 3 rpm API issues that had to be solved in the patch:

     1) /usr/include/rpm/rpmlib.h has includes w/o rpm/ prefix.
      See the CPPFLAGS above.

     2) header.h no longer exists, rpmtag.h has the prototypes needed.

     3) headerGet() (and headerGetEntry() compatibility) has changed  
malloc rules.
     The new rule is
	All data retrieved from a header must be free'd.

Other than that, the change is/was not too bad.

The real problem for net-snmp will be dealing with multiple RPM  
API's, not dealing with
any single API.

And only removing the need to have net-snmp do -lrpm __REALLY__ solves
the fact that there are multiple existing RPM API's around.


Patch attached at end

73 de Jeff

On Jul 22, 2008, at 11:54 AM, Dave Shield wrote:

> 2008/7/17 Jeff Johnson <n3npq@mac.com>:
>     [much persuasive argument omitted]
>> Convinced yet?
> Yes.
> I agree that technically, switching to use /var/cache/hrmib
> is the right approach in the long run.  I don't think there's
> any doubt there.
> But I also know that this isn't a change that I/we can
> simply introduce "overnight".   It might be possible to
> get this approach in place for net-snmp 5.5.  It would
> certainly be possible to use it for 5.6.   But politically,
> there's no way that I could contemplate this change
> for the 5.4.x line - particularly as regards 5.4.2 which
> is just about to move into Release Candidate stage.
>> If more is needed, or we have to do the change more slowly,
>> I can do that too.
> From various things you've said, it sounds as if there's
> an immediate problem with Net-SNMP and Gentoo.
> If you're looking for a way to unstick this, then the most
> practical short-term approach would be to apply the
> necessary patches to make the current code work with
> RPM-5.   If that is feasible (albeit ugly), then I can hold
> off on releasing  5.4.2.rc1 until such patches are in place.
> We can then look towards making the next full release
> use the cache-based approach.   That would probably
> be towards the end of the year.
> Alternatively, I can just go ahead with 5.4.2 with the code
> as it stands, and we'll leave Gentoo stuck until the next
> full release.   Your call.
> Dave
Received on Fri Sep 5 20:15:59 2008
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.