[Pkg-nagios-devel] nagios2 packaging progress

[sean finney]

On Sun, Jan 15, 2006 at 11:36:03AM +0100, Marc Haber wrote:
> > and also how to enable the
> > 1.x urls.
> 
> This needs to be written. How to enable the 1.x urls? Is there more to
> do than answer "yes" to the debconf question? What happens when I say
> "yes" with nagios 1.x still installed?

i would suggest that they either dpkg-reconfigure nagios2-common or
manually edit the apache2.conf config file in /etc/nagios2 (each
line is preceded by a "# nagios 1.x" line).  if you say "yes" with
nagios 1.x still installed, the results are "undefined" as far as
i'm concerned[1].

something that could stand to be added for good form would be to
seed the debconf question in the config script based on whether
the lines are uncommented if the file exists.

> How are the configuration snippets activated? Do they need to be
> linked manually from /etc/nagsos to /etc/apache[2]?

the debconf/maintscript stuff will automatically link them into
the appropriate $apache/conf.d directories and reload the server(s),
though it's probably worth mentioning similar to above how to do this
after installation (via debconf and/or manually).

> >     * ship html docs in a dedicated package
> > 
> > apart from nagios2-common?
> 
> The HTML docs form a significant part of nagios2-common's size They
> don't need to be present on every system running nagios2, but they
> might be wanted on a personal workstation for reference without having
> Nagios2 actually installed. I'd like to see them separated, but I
> don't feel strongly about that.

ah, i see.  that makes sense, then.  while some parts of
nagios2-common should be able to exist happily w/out nagios,
other parts (debconf, apache config, dependencies, etc) probably won't.
i think the best way to do this wrt ftp-master and binary packages is
to name the package nagios2-doc, ship it as a documentation package,
and have nagios2-common depend on it.  what do you think?

> >     * Make sure that cfg-patch breaks package build if patch doesn't apply
> > 
> > the patch process definitely breaks, but i haven't verified the unpatch
> > process does.
> 
> Need to still verify that.

i *think* it should work as we want it, as i already did what fixed it
for the unpack rule (s/-for/for/)... i guess if it isn't we'll
eventually find out :)

> What is upstream's opinion about using later config.guess, config.sub
> before nagios2 release?

i'd guess ethan doesn't care strongly one way or the other, and that if
we brought it to his attention he'd probably include it in upstream cvs.
if not, it's not the end of the world and we could just keep it in the
diff, but i'm all for keeping the diff as clean as possible.

> Would be a possibility, but generally Debian discourages autoreconf at
> package build time. I am also not an expert in autofoo, so I'd prefer
> to convince upstream to use current versions of the tools.

agreed.

> Do you want me to get in touch with upstream?

sure, go ahead and do so.  i haven't made any public mention of
the recent packaging progress, i'm sure folks would be interested.
it'd be nice to coordinate w/ethan for the official release too,
which if our experimental packages clear ftp-master beforehand
could be done in sync.

also, after the first experimental and unstable uploads, we'll probably
also want to post messages to nagios-user and nagios-devel.

> I think that /usr/share/nagios2 would be appropriate. We can always
> move it back to /usr/bin should it show necessary to invoke that file
> on a command line.

agreed.  i'm not sure how to make sure that it works in this alternate
location... perhaps this is another thing to bring up with upstream?

> I'd go for nagios2stats since the word play doesn't work with the 2
> thrown in. I don't feel strongly about that, your decision.

i could go either way really.

> So we'll need to investigate which ping command line the ping plugin
> uses these days.

the build process uses iputils-ping[2].  however, upstream i've committed
a patch that allows us to specify the ping command and arguments
via the configure script.

> > > Yes, that would be needed anyway unless we'd want to have a hard
> > > dependency on the plugins package which kind of defeats the purpose of
> > > factoring out the plugins.
> > 
> > agreed then.
> 
> This, however, introduces an upload dependency between nagios2 and the
> plugins packages. I'll need to think about that before uploading the
> first nagios2 package.

i'm not sure i follow...

> Maybe it is time to migrate the plugins packages to svn then. Who else
> is working on the plugins packages?

just me, afaik.  prety please, go ahead and do so :)  in fact, i'm
interested in the general process you use to do so, as i have a couple
other packages i independantly maintain for which i'd like to do this.



	sean

[1] what will probably happen is either all 1.x links will either still
    point to the 1.x installation, or they will all point to the 2.x
    installation, but such should be discouraged in any case.
[2] via an ugly build-dependency hack.  i've been working on removing
    similar build-deps (like ntp server, ssh server(!)), but now with
    the upstream commits, i'm basically waiting for the next official
    release before making any more changes to the debian version.
-- 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/pkg-nagios-devel/attachments/20060115/fae27f38/attachment.pgp