Date: Wed, 24 Aug 2016 10:23:46 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-ports-bugs@FreeBSD.org Subject: [Bug 212102] net-mgmt/cnagios - Update to 0.33 release, add support for Nagios 4.x Message-ID: <bug-212102-13@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D212102 Bug ID: 212102 Summary: net-mgmt/cnagios - Update to 0.33 release, add support for Nagios 4.x Product: Ports & Packages Version: Latest Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: Individual Port(s) Assignee: freebsd-ports-bugs@FreeBSD.org Reporter: danny@dannywarren.com CC: alexander.4mail@gmail.com CC: alexander.4mail@gmail.com Flags: maintainer-feedback?(alexander.4mail@gmail.com) Created attachment 174009 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D174009&action= =3Dedit cnagios-0.33-2016082300.patch Hi all! I've just released cnagios 0.33 via github, which includes a few important user-contributed fixes. * Fix segfault in time parsing (pull #5 from Peter Hill) * Add support for Nagios 4.x status files (pull #4 from Peter Hill) Attached is a patch that bumps the distinfo and package version.=20=20 Note that I've removed the dependency on net-mgmt/nagios, as the cnagios po= rt now works with either net-mgmt/nagios *or* net-mgmt/cnagios. However, I can't find a clean way to represent that logic with the *_DEPENDS variables. If someone knows a best practices way to do deal with that, I'm curious.=20 So, as things sit right now I think it's fairly reasonable to yank the nagi= os dependency, since: 1) All the other nagios-related ports (such as the nagios-plugins, monitoring-plugins, nagios-plugin-*, etc) also choose not to depend on a specific flavor of nagios, probably for this same reason. 2) You have to have nagios up and running before it's possible to install cnagios, due to the nagios status.dat checks that run during configure time, and as such no *_DEPENDS variable will work for automating this port. 3) Specifying a version via the "--with-nagios-data" option doesn't actua= lly do anything to prevent the need to query Nagios' status.dat file. 4) The cnagios utility doesn't link against nagios at all, and in theory could be installed without nagios and used only for parsing of status.dat files. Thoughts? The real fix is to clean up the build process upstream, which I plan to add= ress in a future release. But for now, we probably shouldn't block Nagios 4.x u= sers since cnagios now works equally well with 3.x and 4.x. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-212102-13>