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
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
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 <firstname.lastname@example.org>:
> [much persuasive argument omitted]
>> Convinced yet?
> 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.
Received on Fri Sep 5 20:15:59 2008