On mån, 2007-10-08 at 12:01 -0700, Wes Hardaker wrote:
> The 5.4.1 code:
>
> - Has an int in snmptrapd.c called "dropauth".
> - This int is referenced (extern) in snmptrapd_handlers.c
> - snmptrapd_handlers.c gets compiled into libnetsnmptrapd
> - TrapReceiver.xs (part of the NetSNMP::TrapReceiver perl module) fails
> to load at run-time because it links to libnetsnmptrapd.so which fails
> to have that variable defined.
>
> I previously patched an RPM (I think) by throwing a "int dropauth" into
> TrapReceiver.xs and was done with it. But that's not a proper patch,
> and it never made it back to the source and it just bit me again. This,
> I think, is the proper way to deal with the library symbol issue and is
> the same way we do it everywhere else in the code: through the use of
> the default_store routines:
>
> So at this point you're wondering why I haven't applied it yet?
>
> Cause the solution also changes the interface for libnetsnmptrap too? I
> think? And may need a libtool version bump?
>
> This is where I need advice... Cause I can probably argue it either
> way. We're dropping the requirement that a library need an external
> symbol (in this case a variable). Anyone know if that requires a
> libtool bump? I actually wouldn't think so, but I'm trying to play good
> developer and ask first.
I think it do need a libtool version bump in the first digit, but that
is my view of it. The alternatives, as I see them, are:
A. The reason for that is that if we assume a program that uses the
library today and sets the variable to a specific value in order
to achieve a specific effect then with your new version the
behaviour of the program have changed, thus this is a removal of
an interface and it should be a major version bump.
B. The reason to refrain from such a heavy bump is that the
interface isn't documented and in that case all you are doing is
to add a new interface and then update the library to use it.
C. The reason to only do the minimal increment is that this is a
mere implementation detail that no user should have relied on in
the first case, so they shouldn't be affected at all.
As I said, I prefer alternative A for this change - this affects user
code, even if all it does is to make the inclusion of a meaningless
variable redundant and it could potentially be a silent behaviour change.
/MF
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
