On Jun 22, 2011, at 10:55 AM, Dave Shield wrote:
> On 17 June 2011 16:53, Jeff Johnson <[email protected]> wrote:
> Wes> The fault is ours for not interacting with you when you originally
> Wes> submitted the patch. I agree: my bad.
>>
>> Well I *thought* that sending the patch to Dave Shield was sufficient
>> back in August 2008. My bad for not checking and reminding.
>
> First of all - my apologies for dropping the ball on this one.
>
NP. I never followed through either …
… but the tight "deadly embrace" of net-snmp doing -lrpm
is having some profound effects everywhere.
Note that Gentoo dropped rpm and stayed down rev because
noone was willing to patch. This is typical behavior for
all linux distress where net-snmp has more recognition
than RPM and so RPM is extremely reluctantly upgraded.
This has been the case all this century … that is the issue I'm
trying to fix:
Uncoupling RPM and net-snmp upgrades.
that my original patch from 1998 has caused. It plain and
simply was _NOT_ the intent to have net-snmp and rpm upgrades
in lockstep, but rather to improve performance on i386/i486 (yes _OLD_)
machines with 16Mb (yes Mb) of memory way back when.
> I couldn't immediately find the actual patch you sent me,
> but it looks as if the framework that's required to support this
> functionality is essentially already in place. All that was missing
> was the one line to initialise the location of this cache directory.
>
The patch for net-snmp is dirt simple. Look at what PLD
is doing: iirc its like 1-2 lines and nothing more for net-dnmp
code to use /var/cache/hrmib/* instead.
The contents SHOULD be generated by RPM itself imho, the
cron script is there solely so that there's a _COMPLETE_
solution for every conceivable deployment, including
Debian and packman if they choose to adopt /var/cache/hrmib.
> I've now tweaked all of the active branches to look for
> /var/cache/hrmib on Linux systems, as an alternative to using
> the RPM libs directly. That should be included in the upcoming
> 5.4.4 and 5.7 releases (both of which are imminent), and will
> appear in the 5.[56].x lines in due course.
>
I will gladly and cheerfully help undo the damage my
original -lrpm patch did anytime, anyplace, you wish.
> I haven't addressed the issue of how this directory is populated and/or
> maintained, but the basic functionality should be available very soon.
>
If net-snmp is headed towards /var/cache/hrmib (or whatever
path is chosen for modern FHS), then the rest of the ducks
will fall into place imho.
The patch to maintain /var/cache/hrmib sychronously with
rpmdbAdd() rpmdbRemove() (the rpmdb registration routines)
is utterly straightforward _IF_ net-snmp sets the direction.
Forking politics leads to instant patch rejection @rpm.org from
me (or anyone else from @rpm5.org) is why net-snmp direction is needed.
Not my problem if the ostriches wish a sandy POV @rpm.org and @redhat.com.
> Sorry for the problems in getting this included.
>
Again NP. I'm ecstatic that the damage my patch did can be undone _FINALLY_.
73 de Jeff
------------------------------------------------------------------------------
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
