Bug#306861: Re: Re: Re: Bug#306861: munin-node: Please include contrib plugins
* Marc Haber apt-get --compile only works on unstable, and I expect a good fraction of munin installation to be backports on stable. I think you're wrong, --compile works in all my Sarge installations (and Woody as well). I think it worked in Potato too, but I've no installation of it easily available so I didn't verify that. So there also won't be any docs advising how to initialize? Will it, for example, matter whether munin-node or munin-contrib gets installed and configured first? The fact that the plugins need to be manually enabled should also be in the package description. I'll probably write some basic documentation. The installation order won't matter - the munin-node package only enables the auto plugins automatically (obviously). The munin-contrib package, on the other hand, won't contain any such plugins, so it's no problem. yuck. That should probably be in the package description. Agreed. -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#306861: Re: Re: Re: Bug#306861: munin-node: Please include contrib plugins
tags 306861 - wontfix quit * Marc Haber The attached patch does this. I am not sure about whether the munin-contrib package needs a postinst as well, and the hack that munin-node's postinst uses to only initialize the plugins which have been installed new might not work any more. It is beyond my knowledge of the package to judge about that. Thanks! I skimmed it very quickly and it looks good to me. I'll probably include it on the next upload. Only thing I wonder, wouldn't it be better to use DEB_BUILD_OPTIONS to indicate that the contrib package should be built? Policy 10.1 doesn't say anything about it being reserved for noopt and nostrip only, at least, and by using an environment variable I can tell the user in README.Debian (or wherever) to just run DEB_BUILD_OPTIONS=munin-buildcontribpackage apt-get --compile source munin instead of doing it in several steps. No strong feelings on this issue from me, though, just curious as I'd probably have used the DEB_BUILD_OPTIONS variable if had implemented it myself. I don't think there should be a postinst with the plugins automatically enabling themself. It's unsupported stuff, I'd like people to know fully what they're doing if they're using them. When 1.2.0 was released I just grepped for half a minute and found around 10 insecure tempfile uses in the contrib plugins - that was when I decided I'd made a mistake letting myself be persuaded to include them in the first place. I fixed those, but now the Solaris/BSD people are complaining because they have no mktemp(1).. sigh, it's impossible to please everyone. Please Cc: me on replies since I am not the original bug submitter. Sure, but there's no need to Cc: me as I get what's sent to the [EMAIL PROTECTED] address anyway. If you Cc: me I get it twice. No big deal though. :-) Kind regards, -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#306861: Re: Re: Re: Bug#306861: munin-node: Please include contrib plugins
Hi Tore, On Mon, May 09, 2005 at 02:04:25PM +0200, Tore Anderson wrote: * Marc Haber The attached patch does this. I am not sure about whether the munin-contrib package needs a postinst as well, and the hack that munin-node's postinst uses to only initialize the plugins which have been installed new might not work any more. It is beyond my knowledge of the package to judge about that. Thanks! I skimmed it very quickly and it looks good to me. Fine! I'll probably include it on the next upload. Only thing I wonder, wouldn't it be better to use DEB_BUILD_OPTIONS to indicate that the contrib package should be built? Probably. I mercilessly ripped the code from the exim4 package which does it like my patch does. Feel free to do it your way in your package ;) Policy 10.1 doesn't say anything about it being reserved for noopt and nostrip only, at least, and by using an environment variable I can tell the user in README.Debian (or wherever) to just run DEB_BUILD_OPTIONS=munin-buildcontribpackage apt-get --compile source munin instead of doing it in several steps. apt-get --compile only works on unstable, and I expect a good fraction of munin installation to be backports on stable. I don't think there should be a postinst with the plugins automatically enabling themself. It's unsupported stuff, I'd like people to know fully what they're doing if they're using them. So there also won't be any docs advising how to initialize? Will it, for example, matter whether munin-node or munin-contrib gets installed and configured first? The fact that the plugins need to be manually enabled should also be in the package description. When 1.2.0 was released I just grepped for half a minute and found around 10 insecure tempfile uses in the contrib plugins - yuck. That should probably be in the package description. I fixed those, but now the Solaris/BSD people are complaining because they have no mktemp(1).. sigh, it's impossible to please everyone. That's why autoconf/automake is in wide use ;) Please Cc: me on replies since I am not the original bug submitter. Sure, but there's no need to Cc: me as I get what's sent to the [EMAIL PROTECTED] address anyway. PEBCAK on my part, sorry. 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#306861: Re: Re: Re: Bug#306861: munin-node: Please include contrib plugins
On Fri, May 06, 2005 at 11:40:16PM +0200, Marc Haber wrote:
Maybe it would be a good idea to prepare the source package to build a
munin-plugins-contrib binary package, but not enabling that binary
package by default. By allowing this, the munin package could be built
locally with munin-plugins-contrib enabled, while leaving munin and
munin-node functionally and content-identical to the official
packages. I find this a good idea, judging from the experience I have
made with exim4.
I can deliver a patch if you want me to.
The attached patch does this. I am not sure about whether the
munin-contrib package needs a postinst as well, and the hack that
munin-node's postinst uses to only initialize the plugins which have
been installed new might not work any more. It is beyond my knowledge
of the package to judge about that.
Please Cc: me on replies since I am not the original bug submitter.
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
diff -u munin-1.2.3/debian/control munin-1.2.3/debian/control
--- munin-1.2.3/debian/control
+++ munin-1.2.3/debian/control
@@ -34,6 +34,25 @@
RRDtool. To see a real example of Munin in action, take a peek at
http://www.linpro.no/projects/munin/example/.
+Package: munin-contrib
+Architecture: all
+Depends: ${perl:Depends}, munin-node
+Description: network-wide graphing framework (local contrib plugins for node)
+ Munin is a highly flexible and powerful solution used to create graphs of
+ virtually everything imaginable throughout your network, while still
+ maintaining a rattling ease of installation and configuration.
+ .
+ This package contains unsupported plugins for the a munin node.
+ .
+ Please note that the plugins installed to munin-contrib are
+ unsupported by the Debian maintainers. Please do not file bugs against
+ this package in the Debian BTS. This package is not part of Debian. If
+ you have it installed, it was built outside of Debian by somebody else.
+ .
+ Munin is written in Perl, and relies heavily on Tobi Oetiker's excellent
+ RRDtool. To see a real example of Munin in action, take a peek at
+ http://www.linpro.no/projects/munin/example/.
+
Package: munin
Architecture: all
Depends: ${perl:Depends}, perl-modules (= 5.8.0) | libparse-recdescent-perl,
librrds-perl, libhtml-template-perl, libdigest-md5-perl, libtime-hires-perl,
libstorable-perl
diff -u munin-1.2.3/debian/changelog munin-1.2.3/debian/changelog
--- munin-1.2.3/debian/changelog
+++ munin-1.2.3/debian/changelog
@@ -1,3 +1,12 @@
+munin (1.2.3-1.0) unstable; urgency=low
+
+ * add munin-contrib infrastructure
+ * not sure about whether munin-contrib should have a postinst, and
+how the init-plugin mechanisms of munin-node and munin-contrib might
+interact
+
+ -- Marc Haber [EMAIL PROTECTED] Sat, 7 May 2005 10:10:21 +
+
munin (1.2.3-1) unstable; urgency=medium
* New upstream release, targeted at Sarge.
diff -u munin-1.2.3/debian/rules munin-1.2.3/debian/rules
--- munin-1.2.3/debian/rules
+++ munin-1.2.3/debian/rules
@@ -2,7 +2,22 @@
export DH_VERBOSE=
-MAKEOPTS = CONFIG=debian/Makefile.config INSTALL_PLUGINS=auto manual snmpauto
+# to build a package with the contrib plugins, either set the following
+# variable to yes, or invoke
+# fakeroot debian/rules buildcontribpackage=yes binary
+# Please do not file any bugs against contrib plugins with the Debian
+# BTS, these are unsupported in Debian.
+buildcontribpackage=yes
+MAKEOPTS = CONFIG=debian/Makefile.config INSTALL_PLUGINS=auto manual snmpauto
contrib
+
+ifeq ($(buildcontribpackage),yes)
+buildpackages=munin munin-node munin-contrib
+else
+buildpackages=munin munin-node
+endif
+
+# generate -pfoo commandline for debhelper
+dhbuildpackages=$(addprefix -p,$(buildpackages))
build: build-stamp
build-stamp:
@@ -21,7 +36,14 @@
install -m0644 debian/plugins.conf \
$(CURDIR)/debian/munin-node/etc/munin/plugin-conf.d/munin-node
-
+
+ for file in `find debian/munin-node/usr/share/munin/plugins -type f`;
do \
+ if ! grep -q #%# family=\(auto\|manual\|snmpauto\) $$file \
+ [ `basename $$file` != plugins.history ]; then \
+ mv $$file debian/munin-contrib/usr/share/munin/plugins;
\
+ fi; \
+ done
+
touch build-stamp
clean:
@@ -35,21 +57,21 @@
binary-indep: build-stamp
- dh_testdir
- dh_testroot
- dh_installdocs
- dh_installchangelogs ChangeLog
- dh_installman
- dh_installinit -- defaults 98 20
- dh_installcron
- dh_installlogrotate
- dh_installdebconf
- dh_link
- dh_fixperms
- dh_compress
- dh_perl
- dh_installdeb
-
