[Pkg-nagios-devel] nagios2 packaging progress

[Marc Haber]

On Sun, Jan 15, 2006 at 07:20:11AM -0500, sean finney wrote:
> 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].

I have documented this.

> 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.

That is not yet implemented, right?

> 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?

Agreed. Done.

> > >     * 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/)...

Yes, it does. Verified.

> > 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.

I have sent a message to nagios-devel, and have implemented a
mechanism to update the files automatically at build-time.

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

Definetely. Just for the record, I consider the -0 upload to
experimental just a slight bit immature.

> > 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'm going to write upstream about this.

> > 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.

I have done the rename to nagios2stats.

> > So we'll need to investigate which ping command line the ping plugin
> > uses these days.
> 
> the build process uses iputils-ping[2].

I see.

> however, upstream i've committed
> a patch that allows us to specify the ping command and arguments
> via the configure script.

For flexibility, it would be great to be able to configure that at run
time, though. For the time being, I suggest leaving things as they are.

> > > > 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...

When we move nagios2 configuration files from nagios2-common to a
plugins package, that move needs to be coordinated between the two
source packages involved. The plugin package containing the
configuration files can only be uploaded once the files have been
removed from nagios2-common. Dragons here.

> > 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 :)

I am planning to have this done until the beginning of next week.
Sorry for not doing it any time sooner, real life has become
surprisingly busy in the last days.

> 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.

I'm going to try to outline it from memory, and when I convert the
plugins package I'll have a typescript running.

(1) Generate svn repository on target host (use the fsfs backend, it's
    much more robust than the bdb backend)
(2) Transfer cvs repository on same host
(3) Use cvs2svn that host with appopriate parameters. The --trunk,
    --branches and --tags parameters don't work as advertised, don't use.
    The data will end up as tags, branches and trunk in the svn
    repository root directory.
(4) svn mv tags, branches and trunk to their final destination
(5) optionally: svn mv tags and branches to the new numbering scheme
(6) svn rm upstream sources from trunk, leaving only the debian/
    subdirectory (does obviously only work if dpatch is already used), svn
    propset mergeWithUpstream on trunk or debian directory (either
    should do, I keep forgetting which).
(7) If the package is big and has had multiple upstream versions
    incorporated, it might be worth dumping the repository and using
    svndumpfilter to remove upstream history to keep the repository small.
    I did this for exim4 when converting exim4 to svn, but not for nagios2.

That should be all.

svn-buildpackage contains a nice HOWTO in /usr/share/doc which has a
chapter about debian/-only layout and how to merge with upstream.

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