[Jonas Smedegaard] > Thanks for your suggestion. It does look like a harmless change, but I > am not fully certain, and have also now switched to use the > init-d-script handler from sysvinit-utils where it is no longer in my > control to tune the code (and that's feature, not a bug).
It does seem harmless, but there are issues to discuss before I believe it is a good idea. > It seems the init-d-script handler has same "wrong" order in its > code as the uwsgi-emperor init script had until now, so I hereby > reassign this bug to sysvinit-utils in the hope they agree it is > harmless to flip the order of things. I do not quite get it. The test in question is intended to make sure the init.d script is not executed when the binary package is removed but not yet purged. The way it is implemented is to check if the executable from the binary package is present. For this to be a problem when overriding $DAEMON in /etc/default/uwsgi-emperor, one do not only have to override the $DAEMON variable, one also have to _remove_ the executable on disk that originated from the package with the init.d. Is this the case here? I am not sure if that is a use case we should support in Debian. I am unable to se another scenario where the order of these code lines is a problem. The $DAEMON value will have the overrided value when the service is started and stopped. Where did I misunderstand? -- Happy hacking Petter Reinholdtsen _______________________________________________ Pkg-sysvinit-devel mailing list Pkg-sysvinit-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-sysvinit-devel