[ Sorry for the delay in replying - I've been off for a weekend's choral singing!]
Dave> In this particular situation, it's not the user's fault Dave> that the MIBs are broken.
Frank> Ok. But it's the user's fault to upgrade the NET-SNMP release without Frank> upgrading the configuration.
Sort of. But the user *using* the system might not be the same as the person who did the upgrade, so might not have realised that their personal configuration settings needed to be changed.
Frank> I think, it's for any large and long standing project like NET-SNMP to Frank> evolve and to make progress, even if it causes some changes that cause Frank> incompatibilties in the first place.
I'd go along with that.
My attitude towards the {UCD->Net}-SNMP transition is that backwards compatability is in general _desirable_, but is secondary to having a clean, maintainable, shiny new system with go-faster stripes. If (for any particular feature) we can have both, then well and good. But if we can only keep backwards compatability by constraining the new stuff, then we look forward rather than back (documenting the changes, of course!)
As far as the MIB parsing is concerned - I'm not too unhappy about rejecting broken MIBs. What I *am* worried about is just dropping out without any word of explanation. Partly this may well be down to how we use 'smiSetFlags' - I need to investigate this further. But the application exit within libSMI itself does rather hamper us somewhat.
I just tried to track down the problem that causes the termination. Can you please send me the module in question?
OK - appended. [Warning - not to be viewed by those of a nervous disposition!]
Further checking seems to indicate that the current UCD distribution *does* actually come with a copy of SNMPv2-SMI that libSMI's happy with. So it's only lazy gits (like me!) who haven't installed the recent UCD-provided MIBs that will get bitten. But that's basically the same argument as above - just shifted back a bit further.
Dave