[Nagiosplug-devel] Re: [Nagiosplug-help] Trouble installing plugins - not templatedperhaps?

[Karl DeBisschop]

On Wed, 2003-09-03 at 08:22, Dag Wieers wrote:
> You can look at the changes I've made at:
> 
> 	http://dag.wieers.com/packages/nagios-plugins/nagios-plugins.spec
> 
> It's not at all closed to the public :)

I realize that. But without the explanations that you provide below, it
can be hard to decide if changes need to be pushed back upstream, or it
upstrem can do anything to help you. Thanks for your feedback.

> Let me summarize the changes I've made:
> 
>  + I added some directives that my buildsystem uses as it seems that 
>    %configure has a problem with Soapbox and I can't build nagios-plugins 
>    parallellized.

what is soapbox?

>  + I added a lot of BuildRequires (RH specific) to help people building 
>    for RH.

We try to keep our spec useful for Mandrake and Suse as well. But any
BuidlRequires that apply generally should probably be pushed upstream
(it looks like most or all can be).

>  + I had to disable INSTALL_OPTS for building as a user.

Should probably be pushed upstream as well. Wonder what you're seeing
that I did not, since I've alway built for RedHat.

>  + I change the location for the perl-binary and for the location of the 
>    plugins.

The Makefile does this. If it does not work, a bug report would help for
perl location. For location of plugins, you do not configure in the
libexecdir, so that's why it does not work for you.

>  + I also added something to compile 2 extra plugins that came in source.

Those are in contrib, right? We typically don't package contirb plugins,
but I'd like to set a goal for the 1.5 development cycle to try and move
a variety of plugins from contrib to core.

>  + During the %install phase I add the utils.pm module to the perl module 
>    path. (The alternative was to add -I flag to every perl-script that 
>    needs it.)

Now that CPAN has a Nagios namespace, we need to redo that, as will you
(though your changes will be smaller than ours).

> Not that many, but most are crucial for a working package.
> 
> 
> > Dag, no offense, but why build your own spec? I have not yet compared
> > your spec with CVS in sufficient detail, but I assume you've put some
> > thought into it. Have we spoken? Have you brought the things you see as
> > shortcomings to the attention of the developers so your improvements can
> > be incorporated into the main code base?
> 
> I have not. Not for the nagios-plugins anyway. I've mentioned the SPEC 
> file on the (nagios) mailinglist though, when I announced the packages.

I'd like to go through this same excercise for nagios as well, if we
could. Maybe after we release the plugins 1.4 alpha, I'll ask for a
summary of what you see as shortcomings in that spec and build process.

> > Since you clearly have access to a RedHat 7.3 machine, couldn't you
> > engage with the devlopers to improve the spec in CVS and still also
> > provide the service of testing releases on the the various releases and
> > maikng those builds available? 
> 
> Actually I just have a 10GB partition that has 4 chroot-installed Red Hat 
> distributions. (RH62, RH73, RH80 and RH9) If you send me the tarball a 
> couple of days before releaseing, I can test-build and give you feedback 
> so that we can fix those things in the resulting release.

That would be great.

> > > I had to do a LOT of customisation to get this to run under Red Hat 7.3
> > > Although I understand Nagios is not for the novice users, these problems
> > > with the plugins proved quite challenging to get it running!
> > 
> > I submit that nagios and the plugins will be more advanced by working
> > from the RPMs that are maintained by Ethan and by the nagios plugins
> > development group.
> 
> Well, Ethan doesn't build any RPM packages and I think the reported 
> problems are not different for the official packages or my packages.
> 
> Nevertheless any feedback to improve the configuration or my packages 
> specifically is very welcome. I've learned that maybe I should put an 
> updated commands.cfg (from the nagios-plugins package) into /etc/nagios/ 
> (given that they work and consist of more plugins). But I will not let the 
> nagios-plugins package change files from the nagios-package. So I guess 
> the 2 projects have to agree on what files and what configuration they 
> ship to make it work without manual intervention :)

We have always done exactly that - that is why nagios ships
checkcommands.cfg and plugins ship commands.cfg - so the packages are
independent. The two projects do agree on what file names to use - the
agrrement is that nagios provides chackcommands, which tries to work
across many plugin releases, while the plugins may provide more bleeding
edge examples, but in a different file which the user must select. t
occurs to me now that if the plugins chose command names that were
non-overlapping with the names in nagios checkcommands.cfg, then both
files could be included at the same time - that might further reduce the
need for manual intervention. Many nagios would create an empty
commands.cfg file in %post so the config would parse, but plugins would
overwrite it? Just a half-formed thought, but maybe it would help.

Thanks again.

--
Karl