Comment # 10 on bug 1117483 from Franck Bui

(In reply to Jaime Caama�o Ruiz from comment #8)
> I think I need to revisit this one.
> 
> On removing DISABLE_STOP_ON_REMOVAL, I agree.
> 
> About DISABLE_RESTART_ON_UPDATE:
> 
> [...]
> 
> I don't see a real use case in avoiding restart. [...]
> 
> But I also don't see a compelling reason to change it, [...]
> 

So it seems that you have mixed opinion about DISABLE_RESTART_ON_UPDATE...

Let's me add another argument against it: when service restarting is disabled
while upgrading the service package, you're in an inconsistent state. The
version of the running daemon doesn't match the one stored on disk and any
attempt for the daemon to run libraries, conf files might fail or lead to a
crash in the worst scenario...

Very few packages (maybe none) need this "feature" and if it was really needed
we shouldn't encourage this practice and make it part of the macro API. Instead
concerned packages should implement their own stuff.

So DISABLE_RESTART_ON_UPDATE is a hack IMHO, and there are much better ways to
implement the zero downtime mechanism these days.

> While I understand using
> the systemd macros is preferable, I guess there is a reason why
> service_del_postun exists and is being used.

The only reason for them is to keep backward compatibilities with SysV init. So
basically if you're maintaining a package that was providing SysV init scripts
which were then later converted in systemd unit files then you should use the
SUSE macros otherwise there's no point and the upstream versions should be
preferred as it makes your package portable across various distros.