[Pkg-nagios-devel] Re: Bug#341748: ITP: nagios2 -- A
host/service/network monitoring and management system
Marc Haber
mh+pkg-nagios-devel at zugschlus.de
Tue Dec 20 17:47:39 UTC 2005
On Tue, Dec 20, 2005 at 11:40:38AM -0500, sean finney wrote:
> sorry for the delay in response, been travelling several timezones
> westward in the past couple days...
No problem.
> On Mon, Dec 19, 2005 at 03:16:46PM +0100, Marc Haber wrote:
> > I therefore suggest the attached patch to debian/control. With this
> > patch, nagios2 does install and cleanly replaces nagios and
> > nagios-common.
>
> nagios2-common shouldn't depend on on nagios2, but instead nagios2
> should depend on nagios2-common. i think there was a rationale
> for that, but now i'm having a hard time remembering.
I think you're right, to have aptitude install nagios2 succeed.
> > I have also re-worked the package descriptions a bit, putting the
> > information important for the local admin first.
>
> thanks for that :)
It would make sense to make these changes for the other packages as
well.
> > - Why does nagios-common depend on fileutils? fileutils currently is
> > only an empty transition package. I'd vouch for removing the
> > fileutils dependency in favor of the already present coreutils
> > dependency.
>
> i believe it was for backwards compatability / backporting.
I understand. Do you still care about woody?
> however,
> i don't have a problem removing it... if someone complains we can
> always put it back.
Right. I'll remove it.
> > - nagios-text has much stricter depends on nagios-plugins, and
> > installing nagios-text pulls nagios-plugins, nagios-plugins-basic and
> > nagios-plugins-standard. What's the reason for nagios2 only
> > depending on nagios-plugins and not on -basic and -standard?
>
> i'm not sure i follow here. they should both be the same, depending
> on nagios-plugins (>= $vers) | nagios-plugins-basic, where $vers
> is the version where the packages were first split.
Ok, I'll streamline nagios2's dependencies to nagios'.
> > - nagios2 doesn't do debconf at all. Is this only "still missing", or
> > did you decide to remove the debconfization?
>
> just an omission... however i'll be somewhat picky about how we
> do webserver configuration, so let's talk about it before we
> build-in support for that. if you have other ideas about how
> debconf could augment the install/configuration process, feel free
> to bring them up.
Currently, I don't see any use for debconf other than webserver
configuration. And webserver configuration can be done more elegantly
by package selection. For example, torrus has two binary packages
torrus-apache and torrus-apache2, which only contain a single file
/etc/apache/conf.d/torrus resp. /etc/apache2/sites-available/torrus,
and depend on the appropriate web server and on torrus common.
Nagios2-apache and nagios2-apache2 would have to depend on nagios2 and
the appropriate web server, and would enable the system to be
operational with a single apt call.
> > - Since nagios2 re-uses /etc/nagios and probably /var/foo/nagios
> > (didn't look), we might get in trouble if the local admin decides to
> > purge nagios after installing nagios2. I'd like to propose going for
> > /etc/nagios2 and /var/foo/nagios2, avoiding conflicts with nagios.
>
> i've never been in this situation, and have to admit that i don't know
> what would happen if a 1.x package was purged after a 2.x package was
> installed.
The 1.x package's postrm script would run, which would in turn zap
/etc/nagios, /var/lib/nagios and /var/log/nagios => *boom*.
You don't want this.
After hosing a few tester's systems with the first exim4 packages, we
decided to be completly independent from exim by coming as exim4
consequently. I am convinced that this was the right decision.
> my initial feeling is that all packages should use /etc/nagios, unless
> there is a compelling reason why they shouldn't. otherwise, we risk
> scuttling any attempt at a reasonably painless upgrade path. i don't
> feel as strongly about other directories.
nagios2 could have its configuration in /etc/nagios2, copying over
/etc/nagios on first installation. This is allowed by policy.
> > Package: nagios2
> > Architecture: any
> > @@ -41,9 +45,6 @@
> > Replaces: nagios, nagios-text, nagios-pgsql, nagios-mysql
> > Provides: nagios, nagios-text
>
> now that i think about it, shouldn't we have a Conflicts in there too?
Only if we want to seamlessly replace nagios on nagios2 installation,
IIRC. What will happen if we omit the Conflitcs?
> On Tue, Dec 20, 2005 at 12:19:02PM +0100, Marc Haber wrote:
> > I have created a wiki page, http://wiki.debian.org/PkgNagios2, for
> > tracking of development issues. This can later also serve as the
> > Nagios2 packages home page (see http://pkg-exim4.alioth.debian.org/).
>
> very nice. i was wanting to have some kind of web-presence for the
> project (pkg-nagios.alioth.debian.org points somewhere currently), but
> was not looking forward to having to maintain that. i think a wiki
> is a better option so thanks for that.
This approach has proven quite handy for exim4, dpatch, and adduser.
Actually, the wiki page I created was morphed from
http://wiki.debian.org/PkgAdduser, so don't be surprised if there is
still "adduser" mentioned in it. I might have been working sloppily.
> On Tue, Dec 20, 2005 at 04:26:35PM +0100, Marc Haber wrote:
> > I have written my first lsb'ized init script.
> >
> > Would it be ok to branch Nagios2 to commit my changes to svn, or is it
> > ok to commit directly to trunk?
>
> as long as you're not going to do any surprise uploads, go ahead and
> commit to trunk. i'll try and keep tabs on the commit messages and
> throw any feedback your way in the meantime.
Great, thanks.
Greetings
Marc
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany | lose things." Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835
More information about the Pkg-nagios-devel
mailing list