Michael Tautschnig schrieb: > [...] >> So I will have to change a really well working email system without any >> reason. Changing configurations wouldn't have been a problem. Removing >> functionality without providing alternatives is. None of the alternative >> solutions recommended by the clamav folks are in any way that simple and >> easy to setup than the clamav-milter was. >> >> Whatsoever, this is nothing debian specific so thanks a lot for helping >> me. Waiting 20 months for the debian distribution to stabilize and the >> first upgrade breaks the system. Should have been a dist-upgrade then. >> There really is no need for debian if things are going that road now. It >> were the great debian packages decoupling the distribution from any >> upstream insanity I chose it for. >> > > Well, you're using volatile. Using volatile will always give you a bit of a > dist-upgrade (which is intentional - you chose to go with volatile to get the > latest and greatest, which it unfortunately wasn't for you usecase).
No! Volatile is not about the latest and greatest. I could use unstable for this. See http://www.debian.org/volatile/ ... The main goal of volatile is allowing system administrators to update their systems in a nice, consistent way, without getting the drawbacks of using unstable, even without getting the drawbacks for the selected packages. So debian-volatile will only contain changes to stable programs that are necessary to keep them functional. ... For packages in the volatile section of the debian-volatile archive, we try to ensure that newer versions do not introduce functional changes or require the administrator to modify the configuration file. Software which cannot be upgraded painlessly will end up in the section volatile-sloppy. ... > > You've got to choose: Somewhat older clamav stuff (0.94 + security upgrades) > or > the latest upstream, via volatile. Again no! Volatile is not about the latest upstream releases - that's unstable. Volatile is about backporting upstream changes needed to keep a stable package functional without unstabilizing it. Upstream has chosen to rewrite clamav-milter > in a minimalistic way. There is nothing that we as the Debian package > maintainers of clamav can do about it in any reasonable way, especially with > the > lack of knowledge that the now dropped features were so much required. Of course you could do something about it. You are the package maintainers. As such, you stand between upstream and the debian distribution. Its a debian package maintainer's job to decouple the distribution from upstream development somehow, I think, and not to blindly follow upstream development. Whatever upstream decides, there is no reason to remove functionality from a stable program via volatile. You could have left the old clamav-milter untouched instead of replacing it. We are talking about how volatile and stable go together and that's well stated on the volatile website. I would never have expected volatile to break anything. It now did. For the first time since years, I admit. It should > be noted that, thus far, you're the only one telling the pkg-clamav team that > this is the typical usecase. We'll likely need to put something about these > missing features in the upgrade notes of squeeze, but upstream may also decide > to re-add those features until the release of squeeze, we don't know. The pkg-clamav team, yes. The clamav archives contain a few posts by others having the exact same issues. Nearly everyone having used the old clamav-milter the way I did asked to make the new clamav-milter work the same way. No arguments about *why* clamav-milter got changed that (from my point of view) drastically so far. I understand that this is to be addressed to upstream and not to debian in any way, of course. > >> Btw, the clamav upgrade really brought a /etc/default/clamav-milter file >> with it. This new file contains the line >> >> RESTART_AFTER_CLAMD=yes >> >> and as soon as this is set to yes, clamav-milter cannot be started >> anymore stating a warning that clamd may be needed and that it will be >> started by clamd. clamav-milter will not be started by clamd for me. >> > > No, it should cause clamav-milter to be RE-started in case clamd is upgraded. > It > should not stop anything from being started. If it does, please copy&paste the > error message here. > > Best, > Michael > Having RESTART_AFTER_CLAMD=yes in /etc/default/clamav-milter I cannot start clamav-milter by executing /etc/init.d/clamav-milter start. smtp:~# /etc/init.d/clamav-milter start clamd may be required to run /usr/sbin/clamav-milter, clamav-milter will be restarted by clamav-daemon (warning). I have to set RESTART_AFTER_CLAMD=no manually after the upgrade to make /etc/init.d/clamav-milter work again. smtp:~# /etc/init.d/clamav-milter start Starting Sendmail milter plugin for ClamAV: clamav-milterWARNING: Ignoring option local:/var/run/clamav/clamav-milter.ctl . Don't know where this "Ingoring option" warning comes from. Btw, I got the new clamav-milter working nearly the same way as it did before. Its just those missing email notifications to the recipients which are lacking. That's what users are asking for now - "I am missing an email and did not get any notification. Can you look what happened ?". That's exactly the reason I enabled those notifications a few years ago. -- Christian _______________________________________________ Pkg-clamav-devel mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/pkg-clamav-devel
