On Sun, Mar 16, 2008 at 03:14:58AM +0100, Michael Biebl wrote: > Craig Sanders wrote: > > On Sun, Mar 16, 2008 at 01:16:22AM +0100, Michael Biebl wrote: > > > > >>>> One of the reasons, why it is done this way, ist that you can't > >>>> guarantee a clean shutdown of the daemon, when you have replaced it's > >>>> files, while it is still running. > >>> name one daemon where that's a case. > >> I already gave you one. > > > > no, you didn't. you made an assertion without any evidence, not even > > a single example. > > Again: Imo a service should be stopped by the init script which > was written for this specific version, because the maintainer can > only test it for this version. The alternative would be, that the > maintainer tests the upgrade path from any previous version and adds a > lot of special casing to the maintainer script (which *will* lead to > errors, believe me).
dpkg passes more than enough information to the scripts for the script to be able to make decisions about what to do. see sections 6.5 & 6.6 of /usr/share/doc/debian-policy/policy.txt.gz, from the debian-policy package. (there are also pdf and html versions under the same directory) a service should be stopped during upgrade ONLY if there is no other alternative. even if that means writing a bit of code in the prerm or postinst scripts. btw, the only upgrade path that MUST be checked and handled as appropriate is the upgrade from the previous stable release (incl. point releases and security updates) to the current package version. people who use testing or unstable understand and accept the risk of breakage within the development cycle. you can do better than that if you want, but that's optional. > Second, if you replace files while the daemon is still running, > this can lead to all sorts of subtle failures, e.g. daemons that > dynamically load functionality via shared modules (as rsyslog does) > might crash. 'MIGHT crash' is a whole lot better than 'definitely WILL be shut down for the entire duration of the upgrade - many minutes or even hours(*)'. with the former you have a chance of significant downtime during upgrade. with the latter, you are guaranteeing significant downtime during upgrade. (*) possibly days or longer in the case of remote upgrades of packages like ppp or sshd, if they were to shut down during the upgrade. depends on how far away the remote machine is and how long it takes to get someone there to fix it at the console. craig -- craig sanders <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
