I did look at the docs before sending in the fragment. In no place
in the LSB documentation does remote_fs imply that local_fs has
already happened, so technically, having both is a good thing. Many
scripts have both. /usr can technically be remote_fs. I was trying
to change as little as possible with my submitted fragment, but I
suspect the more conservative remote_fs and local_fs is the right
answer.
Do we need clamav-daemon in there? I don't object to the other
deps, but
clamav-daemon really shouldn't need to be started before amavisd-
new...
Again, it's a windowing problem. Amavisd-new technically doesn't need
to be started before the MTA, but the services should be in place. If
clamav-daemon isn't around, we may or may not fall back to clamscan,
but amavis is looking to connect to the control socket for clamav-
daemon, so I think it's perfectly reasonable to put it in the should,
along with they SQL databases. It's principle of least astonishment.
"please just work right"
Again, it shouldn't break things that don't have any of the "should"
severs (or do).
Did you test it?
Extensively, under my environment, which is postfix+amavis+clamav
+spamassassin but not using LDAP or MYSQL for amavis-purposes (but
having MYSQL on the machine for other reasons and no LDAP at all).
This should give us reasonable coverage.
The only change I can see is adding the more conservative $remote_fs.
It's actually amazing how many scripts in /etc/init.d/rc are still
somewhat broken, networking stuff like apache not waiting for $named
and $time. Obvious bugs... but we'll at least get our stuff right.
The easy way to test it is to make changes, then just run insserv and
you can see (sanity check) where the file actually shows up in /etc/
rc2.d ... and then reboot at will.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
