I posted this as a comment on the blog, but I'm duplicating here:
RHEL and Debian (and their respective derivatives) have different philosophies on packaging, which is why you see this result.
The RHEL philosophy is simple; package installation only installs the package, starting daemons is a separate process.
The Debian philosophy is that installing a daemon should also make that daemon run, unless it's not possible the make the daemon run securely by default. Things like the /etc/default RUN="no" aren't the package maintainer trying to be clever, but rather them following Debian packaging guidelines. There also the reason you see things like MySQL listening only on the loopback interface by default on Debian.
One you understand this the decisions seem a bit less crazy.
For me, the big issue with the Debian approach isn't on installation, but rather on upgrade. On Debian, running 'apt-get upgrade' on a live server can cause an unspecified amount of downtime. If you're upgrading MySQL, MySQL will get restarted. If you're upgrading a library on which multiple daemons rely, they will also get restarted. yum upgrade on RHEL doesn't suffer from the same problem, and you can schedule the restart yourself.
Again, this is because of a philosophical difference. On Debian, the idea is that if you've asked to upgrade something, it should be upgraded. On RHEL, you can upgrade a package, but continue to run the old (potentially insecure version).
> If you're upgrading MySQL, MySQL will get restarted.
Or specifically, it will get stopped, your packages will spend 15 minutes updating (or longer if there's an interactive prompt mid way and you aren't paying attention), and then it will get started again.
I'm quite happy with the debian way of doing things, but I'd really like it if apt-get was smart enough to stop / upgrade / start individual services, rather than stop-all / upgrade-all / start-all...
It depends on the upgrade sequence; I've definitely seen the behavior of a service getting temporarily shut down during something like preinst upgrade, a bunch of packages being installed, and only at the end during configure them all being restarted.
Report a bug then, or check if this is really possible to restart the service after installation. In some cases that may be the only reasonable way to do it. For example services based on scripts/libraries which get dynamically reloaded on each request cannot be updated while they're running, because it would cause mismatch between the components. Killing them, updating all files and starting again is the only way to do it.
As you said - it's not a debian-specific thing. Some packages may do it if they explicitly require it (and I haven't seen one doing this in the official repos so far).
I did not and do not consider it a bug; it was just inconvenient; it was really really inconvenient once when I did an upgrade involving hundreds of packages.
If you have very large buffers for InnoDB to flush and safely write out to disk it can take a long time. Usually not 15 minutes but it can be several minutes.
RHEL and Debian (and their respective derivatives) have different philosophies on packaging, which is why you see this result.
The RHEL philosophy is simple; package installation only installs the package, starting daemons is a separate process.
The Debian philosophy is that installing a daemon should also make that daemon run, unless it's not possible the make the daemon run securely by default. Things like the /etc/default RUN="no" aren't the package maintainer trying to be clever, but rather them following Debian packaging guidelines. There also the reason you see things like MySQL listening only on the loopback interface by default on Debian.
One you understand this the decisions seem a bit less crazy.
For me, the big issue with the Debian approach isn't on installation, but rather on upgrade. On Debian, running 'apt-get upgrade' on a live server can cause an unspecified amount of downtime. If you're upgrading MySQL, MySQL will get restarted. If you're upgrading a library on which multiple daemons rely, they will also get restarted. yum upgrade on RHEL doesn't suffer from the same problem, and you can schedule the restart yourself.
Again, this is because of a philosophical difference. On Debian, the idea is that if you've asked to upgrade something, it should be upgraded. On RHEL, you can upgrade a package, but continue to run the old (potentially insecure version).