I feel that Net-SNMP should follow what the OS maintainers are willing to support. If they're saying they're only going back 2 versions; I strongly urge the team to cut the support for them loose. I understand the team's desire to maintain backwards compatibility; however, we have to consider the baggage the project is taking on here. At the very least, there's code sitting around for systems that may not be in use anymore. Worst case, Net-SNMP drags OpenBSD along because of a newsworthy vulnerability.
Now, in the spirit of spreading the responsibility wealth I would also ask that distro maintainers also do their share and submit patches to remove code specifically made for a distro version that's not supported anymore. On Fri, May 4, 2018, at 9:01 AM, Stuart Henderson wrote: > On 2018/05/04 10:37, Robert Story wrote: > > On Fri, 4 May 2018 13:58:43 +0100 Stuart wrote: > > SH> This is needed for OpenBSD 5.6+. It does break older versions > > SH> but 5.6 was released in 2014 and support for this ended Oct > > SH> 2015; I'd find it unlikely that anyone still running this would > > SH> be building up-to-date net-snmp. > > > > We try really hard to maintain backwards compatibility. Any chance > > you could throw in a configure test and some ifdefs? > > Personally I think it's a disservice to users to enable them to run > with such an old version of OpenBSD - there's a 2-release cutoff for > important fixes in the base OS and 6 months at the most for security > fixes in ports - we [OpenBSD] don't have the ecosystem where an OS > vendor provides many years of support and backports for an older major > version as is the case with some Linux distros. > > But I'd very much like to cut down the amount of patching we have > to do in the port, so if you really need that I'll take a look :-) > > I'm not good enough at autoconf wrangling to come up with a feature test > to figure out whether it's using CIRCLEQ or TAILQ. If it's necessary to > support this then the simplest way to cope is probably to condition on > OpenBSD >= 201411 (defined in sys/param.h), would that be acceptable? > > (The current mechanism used for version selection in net-snmp doesn't > fit OpenBSD's release numbering; there are no "major releases", a change > in the first digit of a release indicates only the passing of time, > but that doesn't seem like something good to poke at during your rc > cycle). > > Thanks. > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Net-snmp-coders mailing list > Net-snmp-coders@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/net-snmp-coders -- Thanks, Keith (pantherse) ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders