Comment # 12 on bug 1117483 from Jaime Caama�o Ruiz

>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...

I agree. So on one side we have this problem (and we have 'zypper ps' warning
to check it). On the other side, if we restart, the information stored on OVS
database is lost, which on a second thought, still may affect ovs standalone
users since not all of them will be running an upper management tool and from
an ovs package perspective we probably should not make such assumptions.

So we have good reasons to go either way.

>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.

Understood. It looks like that is the case for the SLES11 upgrade path.

>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.

I don't understand the problem with the macro API. We could use
%service_del_postun -n" instead of DISABLE_RESTART_ON_UPDATE. %systemd_postun
would behave in the same way.

---

However, where I wanted to get to if this corresponds to a real need or problem
that we have in our field systems or labs. If we have no other reasons, then
someone can come back later with a different opinion and then we are in a
spiral of changing it back and forth. Why don't we accept the status quo that
we have now until we have a good reason to go one way or the other.