Le 11/03/2016 14:59, Miroslav Suchý a écrit :
Dne 11.3.2016 v 14:41 Jean-Marc LIGER napsal(a):
> Your feedback was helpfull to resolve this trigger issue :
>
https://copr.fedorainfracloud.org/coprs/jmliger/virt6-upstream/build/167475/
>
> I will submit a patch to the libvirt list.
What was the cause and what was the solution? I'm curious.
The following instructions where sequentialy applies for systems without
systemd which cause a trigger issue.
%triggerpostun daemon -- libvirt-daemon < 1.2.1
%triggerpostun daemon -- libvirt-daemon < 1.3.0
I inverse the order and put the %triggerpostun daemon -- libvirt-daemon
< 1.2.1 in the next test case for non systemd.
diff -uri a/libvirt.spec.in b/libvirt.spec.in
--- a/libvirt.spec.in 2016-03-01 04:21:48.000000000 +0100
+++ b/libvirt.spec.in 2016-03-11 14:57:43.347652313 +0100
@@ -1767,16 +1767,6 @@
fi
%endif
- %if %{with_systemd}
- %else
-%triggerpostun daemon -- libvirt-daemon < 1.2.1
-if [ "$1" -ge "1" ]; then
- /sbin/service virtlockd reload > /dev/null 2>&1 || :
- /sbin/service virtlogd reload > /dev/null 2>&1 || :
- /sbin/service libvirtd condrestart > /dev/null 2>&1
-fi
- %endif
-
# In upgrade scenario we must explicitly enable virtlockd/virtlogd
# sockets, if libvirtd is already enabled and start them if
# libvirtd is running, otherwise you'll get failures to start
@@ -1789,6 +1779,12 @@
/bin/systemctl is-active libvirtd.service 1>/dev/null 2>&1 &&
/bin/systemctl start virtlogd.socket || :
%else
+ %triggerpostun daemon -- libvirt-daemon < 1.2.1
+ if [ "$1" -ge "1" ]; then
+ /sbin/service virtlockd reload > /dev/null 2>&1 || :
+ /sbin/service virtlogd reload > /dev/null 2>&1 || :
+ /sbin/service libvirtd condrestart > /dev/null 2>&1
+ fi
/sbin/chkconfig libvirtd 1>/dev/null 2>&1 &&
/sbin/chkconfig virtlogd on || :
/sbin/service libvirtd status 1>/dev/null 2>&1 &&