On 03-08-2010 21:35, Heiko Baums wrote:
Am Tue, 03 Aug 2010 21:40:20 +0200 schrieb Attila<vodoo0904@xxxxxxxxxxxxxxxx>: 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.
