[Nagiosplug-devel] update for nagios-plugins and debian

[sean finney]

hi,

On Thu, Oct 13, 2005 at 12:22:29PM +0100, Ton Voon wrote:
> My angle is that, obviously, I would like bugfixes to come back  
> upstream. Let me know if there is anything I can do to facilitate this.

seeing as i'm now in charge of the nagios-plugins in debian, and am
also on the team here, i think it will be pretty easy.  i probably
won't always do them at the same time, but it should be fairly easy
to track what bugfixes i haven't yet merged (as you'll see below)
in debian.

> I'm also interested in how you are marking differences between trees.  

debian has a development tool called dpatch, which is what i use
here and pretty much everywhere else.  you basically keep the "upstream"
source pristine, and have a directory of ordered patches which are
applied before building the package.  thus, when 1.4.3 comes out with
the fixes flown in from debian, all i have to do is remove the patches
from the directory (and if i forget to the patches will fail to apply
and i'll pretty quickly figure out why).

in fact, for most projects, i don't keep the upstream source in an scm
at all, and  only keep the ./debian directory in subversion.
svn-buildpackage (a debian tool) knows how to unpack original upstream
tarballs, add ./debian, and then the dpatch+the standard build process
takes care of everything else.    this guarantees that some combination
of configure/make/make clean/editing doesn't corrupt my "original"
source, and also keeps the footprint of stuff being tracked to a
bare minimum.

unfortunately cvs-buildpackage (another debian tool) isn't that smart,
and alioth doesn't yet support svn, so i'm stuck keeping all of
nagios-plugins in cvs on alioth.  the only time i will modify
things outside of ./debian is when i'm introducing the next upstream
version of the plugins.  works pretty well as long as i don't
mess up the cvs tags and/or accidentally commit something in the
source outside fo ./debian.

> I notice you are using an actual "exploded" CVS tree. Does your  
> method work well when syncing trees?

yeah.  the only ./debian in svn really works the best but... but if
that's not a choice, this works okay too.  basically when a new upstream
version comes out, i merge the trees (there's a tool for that too), do
a bit of manual inspection to add new files and remove deleted files,
and then tag it as the next upstream version.  cvs-buildpackage
takes care of the rest for me.


	sean
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <https://www.monitoring-plugins.org/archive/devel/attachments/20051013/5bf481e9/attachment.sig>