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]
