On Mon, Feb 26, 2007, Marcus Better wrote: > It may be easy, but it will get less easy when more people start filing bugs > after removing some essential kernel feature.
Applications are supposed to error out when required features are missing, but this is all a separate issue. > And we would have to do the > same for any other apps that happen to rely on this module, ending up with > potentially lots of init scripts that load modules on their own. > I would like to close this bug as a non-issue. Well, it's up to you, but I think it's common practice to support this on a best effort basis: bee% grep modprobe /etc/init.d -rl /etc/init.d/libdevmapper1.02 /etc/init.d/lvm /etc/init.d/modutils /etc/init.d/udev /etc/init.d/discover /etc/init.d/module-init-tools /etc/init.d/acpid /etc/init.d/pcmciautils /etc/init.d/nfs-common /etc/init.d/alsa /etc/init.d/apmd /etc/init.d/avahi-daemon /etc/init.d/hotkey-setup /etc/init.d/cupsys /etc/init.d/lwresd /etc/init.d/ipw3945d /etc/init.d/mdadm-raid /etc/init.d/vmware (This is only on my laptop obviously, YMMV.) My suggestion would be to downgrade this to wishlist and add a modprobe when you find the time. > (Besides the "problem" is in jsvc, not Tomcat.) Oh; I suppose this bug can be reassigned or perhaps jsvc can be made a shell wrapper which loads the module as well; or even tomcat can source an "init" shell snippet from the jsvc package before invoking jsvc then? -- Loïc Minier <[EMAIL PROTECTED]>
