[Nagiosplug-devel] Re: netsaint-plugins-1.2.9-4.rpm dependancy breaks on RH 7.2

Terje Bless link at pobox.com
Wed Apr 3 03:10:13 CEST 2002


Subhendu Ghosh <sghosh at sghosh.org> wrote:

>On Fri, 29 Mar 2002, Terje Bless wrote:
>>Subhendu Ghosh <sghosh at sghosh.org> wrote:
>>
>>>Plugin development in nagiosplug is starting to happen offline.
>>Why offline?
>>
>A lot of wading through code... its hard to discuss wading thru code ;)

Ah, good point. :-)

BTW, you haven't considered setting up an IRC channel on OpenProjects.net?
I'm not really much of an IRC person, but I've found it an excellent
communications channel -- to complement mailinglists -- on a few other
development projects. It works great for brainstorming and encouraging
synergy to occur, as well as getting more eyeballs on a problem more
quickly.


>perhaps - having the rpm being dependent on openssl0.9.6a and flag a
>warning during install would be better.

Well, either make the depandance explicit (on libssl.so.1, I think, not
OpenSSL 0.9.6a) or produce a new, "bug fix" version that will work with
OpenSSL >= 0.9.6b (IOW, libssl.so.2).

Many people will be running 0.0.7 in production until Nagios 1.0 goes final
-- and a little longer even, probably -- and silently failing to detect an
error is about the worst failure mode you can have. And "check_http" isn't
exactly an obscure and little used plugin.

Requiring libssl.so.1 will prevent installing netsaint-plugins on stock Red
Hat 7.2!



BTW, you have a dependance on libcrypto -- also from OpenSSL -- too that
should be dealt with in the same manner as libssl.so.1 whatever you choose
to do with it.


>>Cool! I'm looking forward to it. With any kind of luck I should be able
>>to contribute some code towards the Perl plugins.
>
>Always welcome.

Of course, this will also depend on how open the development process is and
how well it's documented. I don't usually have the time to follow the
development closely, and to dive in when I have a week or two it's
absolutely essential that there exists documentation that describes what
the current status is, where the current focus is, what remains TODO and
the relative priority of TODO items, as well as general developer
guidelines and coding standards.

Just FYI, as I expect I'm not the only one that would need that to be able
to make any substantial contributions.



-- 
We've gotten to a point where a human-readable,   human-editable text format
for structured data has become a complex nightmare where somebody can safely
say  "As many threads on xml-dev have shown, text-based processing of XML is
hazardous at best" and be perfectly valid in saying it.      -- Tom Bradford





More information about the Devel mailing list