On Sat, 2009-05-30 at 08:37 -0500, Dan McGee wrote: > > I think I can safely speak for most of the developers when I say Arch > will *never* get in the business of restarting daemons. Ever. If we do > it is a bug, because the implications of it are just too great. Think > about upgrading the httpd package on a relatively high-traffic site > (e.g. archlinux.org). Think we want the webserver to just restart > whenever it wants? Now do the same with xinetd, mysql, and you start > to see huge problems. To process a kernel update, your system should be rebooted too. Should we do that from post_upgrade also? :P I agree with Dan here. I don't like packages restarting or stopping crap behind my back. Since we do not have configuration file merging integrated in pacman, I also see no way to do this in a good fashion. Let's say you upgrade apache 1.3 to 2.2, after which the configuration scheme has changed completely. Just stop the old apache, install apache 2.2, install a shitload of pacnew files, start apache and it fails and won't come up again until the administrator updates all configs. Compare this to the case where apache will keep running until the next run of logrotate where it will crash then. Another thing is upgrading in chroots. Last week I've been updating a debian etch chroot install to debian lenny. I had to edit the postrm and postinst files for postfix and snmpd, because they couldn't stop and start postfix and snmpd. Apt would not let me continue without fixing this first. I ended up with two chroots that didn't allow me to umount the bind-mounted /proc, /dev and such, with no way to find out which stupid daemon was still running inside the chroot.
