On 03-08-2010 21:35, Heiko Baums wrote:
Am Tue, 03 Aug 2010 21:40:20 +0200
schrieb Attila<vodoo0...@sonnenkinder.org>:
It's so simple and every Linux user should or must know this. If a
daemon or any other software is updated it must be restarted either to
use the new version or to get it working if the running version broken
by the update. And the config files need to be checked and customized
after every update.
That's a common and necessary task of a Linux admin which doesn't need
and in my opinion shouldn't be done by the package manager, because the
package manager can't decide which config files I need or want to
adjust and when I can and want to restart which daemon. Restarting
daemons automatically by the package manager can break a lot and can do
a lot more harm.
An argument can be made that this approach makes a rolling release less
attractive to users who have invested heavily in the supported
repositories. I heard this much just recently from a former Arch user;
The possibility of an an unpdate resulting in a post-update maintenance
nightmare to get the machine up and running again can be a little scary.
But I do agree with you. I just don't think that waving the KISS
principle as a weapon achieves much. It's a tool. And it has its
disadvantages. Users must be aware of them.
If a user keeps the machine updated regularly and follows a tight
upgrade schedule, they will have to deal with only minor incidents once
and a while. And all easy to handle. Stop daemon, start daemon. On the
other hand, if a user decides to update their machine once every two
months, they must understand that it is not the rolling release system
that is at fault. It's them for not understanding what's the point of a
rolling release.
