[Pkg-nagios-devel] Bug#707841: check-mk: Consider packaging the agent and the server part independently

[Bernhard Schmidt]

Package: check-mk
Severity: wishlist

Hello check-mk maintainers,

this is just a suggestion/idea, not even a wishlist. I work quite extensively 
with check-mk and I just had the following idea. Maybe you already thought
of it and rejected it, but here it comes.

src:check-mk currently builds two totally different kinds of packages

check-mk-agent{,-logwatch}:
- single bash script for the main agent, easy to understand
- very short bash scripts for optional plugins
- very few dependencies, autodetects presence of optional tools and skips checks
  gracefully
- totally self contained
- quite good track record of being up- and downwards compatible with different
  server versions
- few changes in the code, occasional additions and fixes in the code that
  usually don't break anything
  http://git.mathias-kettner.de/git/?p=check_mk.git;a=history;f=agents/check_mk_agent.linux;h=78902caff3c26067b08e2f6a8451fdcdec788a3c;hb=HEAD
- additional checks are usually only a few lines and self-contained 
- installed on every monitored server

These packages are in my eyes prime backports material and quite suitable
for easy fixes in stable point releases


check-mk-config-*, check-mk-server, check-mk-livestatus, check-mk-multisite:
- quite complex
- often backwards incompatible changes in perfdata labels (-> pnp4nagios breaks
  old stats) or in WATO configuration, requiring manual intervention on
  upgrades
- quite often regressions and changed behaviour in new releases
- not really well supporting distro packages anyway, upstream pushes use of
  their 3rd party OMD packages

These packages are hard to keep updated, especially considering that Debian
is supposed to keep automatic upgrade paths through the versions. A lot of
people are also switching to OMD anyway, making the server parts low popcon.


Would it be an option to split the package into two source packages (with the
same .orig if that's possible), and keep the agent closer to upstream versions?
Of course the best would be to keep all packages updated, but it seems to 
be much more work to do so.

Thanks for your opinions,
Bernhard