spark rpm

[Karl DeBisschop]

On Tue, 2003-03-18 at 11:29, Jeremy T. Bouse wrote:
> 	I have actually been working with the CVS code for the plugins
> to generate a Solaris package which can be installed/removed with
> pkgadd/pkgrm... It has not been included into the repository yet but I
> have successfully made Solaris packages on Solaris 7 and 9 at this
> time... I'm tracking down a build issue in the CVS code on Solaris 2.6
> which was reported to me today... 
> 
> 	I could get a Solaris 8 nagios-plugins package made with the
> base plugins (read as no MySQL, PostreSQL, LDAP, OpenSSL support) as
> they require additional packages be installed and ld library paths be
> changed to get the plugins to execute... 
> 
> 	The package does install into /usr/local/nagios and currently
> only includes the plugins, not the command.cfg or anything else for
> configuration... 

With regard to your package, Jeremy, I'd like to try and build in
support for packages of many sorts. To that end, I have thought about a
'pkg' directory that all these should go into.

Unfortunately, from this point of view, debain IIRC requires that the
debain directory be located at the top of the tree. But RPM spec can be
moved into a pkg directory. I would propose putting packaging stuff for
Solaris in <nagiosplug>/pkg/solaris -- if there's version specifc stuff,
naybe those parts would go into pkg/solaris/2.6 for eaxample.

Seem reasonable?

If so, would you go ahead and commit your new packaging stuff to CVS
HEAD in that manner?

Then we could add packaging tools for FreeBSD ports, and so on, as we
get the chance.

As for RPMs, right now we have one general spec, which is more geared
toward RedHat than any of the other distros. It might be nice to have
something like pkg/mandrake to accomadate a Mandrake-specifc spec, etc.
But I don't know of any way to get 'rpm -ta' to respect my wishes on the
matter. I'd like it even more if I could include the parts that were
distro specific, and not need to maintain the spec in multiple
instances. But that's entering into the realm of fantasy, I think. (at
least with the CVS tree -- but maybe the distribution tarball could do
something like that, since the spec is processed by a make-hook anyway)

I'm open to suggestions on how to best handle the various RPM flavors.

As I said, AFAIK, debian has policy standards that preclude it from
playing nicely with other package formats in this manner - it demands a
top level directory of its own. Please correct me if I'm wrong. 

At one point in the netsaint plugins, I thought we had a debain
directory in CVS. I would support ressurecting that, especially if we
can get get the debain maintainer on board now that we have an actual
release.

--
Karl



-------------------------------------------------------
This SF.net email is sponsored by: Does your code think in ink? 
You could win a Tablet PC. Get a free Tablet PC hat just for playing. 
What are you waiting for?
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. 
::: Messages without supporting info will risk being sent to /dev/null