В Thu, 20 Nov 2014 13:37:13 +0100
Guido Berhoerster
* Andrei Borzenkov
[2014-11-20 13:28]: On Thu, Nov 20, 2014 at 2:50 PM, Guido Berhoerster
wrote: * Andrei Borzenkov
[2014-11-20 12:46]: On Thu, Nov 20, 2014 at 2:32 PM, Guido Berhoerster
wrote: * Andrei Borzenkov
[2014-11-20 12:25]: On Thu, Nov 20, 2014 at 1:38 PM, Guido Berhoerster
wrote: > * Ludwig Nussel [2014-11-20 11:20]: >> Stanislav Brabec schrieb: >> >Ludwig Nussel wrote: >> >>Stanislav Brabec schrieb: >> > >> >>>Presets added later than services (from util-linux.spec, works only if >> >>>the preset is part of the package): >> >>> >> >>>%pre >> >>>%service_add_pre {service}.service >> >>>if [ $1 -gt 1 ] ; then >> >>> if ! test -f /usr/lib/systemd/system-preset/{service preset file} ; then >> >>> echo -n "" >/run/rpm-%{name}-update-{service}.socket-new-in-upgrade >> >>> fi >> >>>fi >> >> >> >>That is no longer necessary. %service_add_pre does that itself since >> >>January. >> > >> >Are you sure that it helps in situation, where service was introduced in >> >past, and now we are introducing its preset? >> >> You are right. The macro only handles the case where a new service is >> introduced. I agree that >> >> >[...] >> >I even don't see a reasonable fully automatic solution. The process >> >cannot discriminate between "no preset is present because maintainer >> >forgot to define it" and "no preset is present because the implicit >> >default off is OK". >> > >> >So I think that any later preset and systemd-presets-branding-* change >> >need a special handling in scripts like the code above. >> >> Is it really worth the effort? We are talking about an optional package >> here. So if the admin installed the package but did not enable it's >> services it could be assumed that this is intentional. So even if the >> default policy for the package changed to enable a service by default >> now that doesn't mean it needs to enforce that on update. > > What about packages which provided boot.* sysvinit scripts > before, which are after conversion off by default? That seems > wrong and unexpected to me and I'd like what I should do in that > case. Concrete example: > https://build.opensuse.org/request/show/262369 I expect per/post macros to handle this properly (i.e. service replacing initscript must be left in the same state as initscript). If not, it sounds like a bug to me.
I'm happy to fix it if someone tells me how that should be handled, https://en.opensuse.org/openSUSE:Systemd_packaging_guidelines says nothing about it. IMO former boot.* scripts should always be enabled by default,
Really? Then why I have to do
chkconfig boot.multipath on
on every SLES installation? :)
I believe boot scripts were handled just like other run levels and could be disabled and enabled as needed.
They are not even listed by chkconfig.
boot.apparmor 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.cgroup 0:off 1:off 2:off 3:off 4:off 5:off 6:off boot.cleanup 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.clock 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on S:on boot.compliance 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.crypto 0:off 1:off 2:off 3:off 4:off 5:off 6:off boot.crypto-early 0:off 1:off 2:off 3:off 4:off 5:off 6:off boot.cycle 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.debugfs 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.device-mapper 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.dmraid 0:off 1:off 2:off 3:off 4:off 5:off 6:off boot.efivars 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.fuse 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.ipconfig 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.kdump 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.klog 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.ldconfig 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.loadmodules 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.localfs 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.localnet 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.lvm 0:off 1:off 2:off 3:off 4:off 5:off 6:off boot.lvm_monitor 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.md 0:off 1:off 2:off 3:off 4:off 5:off 6:off boot.multipath 0:off 1:off 2:off 3:off 4:off 5:off 6:off boot.open-iscsi 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.proc 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.quota 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.rootfsck 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.scpm 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.swap 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.sysctl 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.sysstat 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.udev 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.udev_retry 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on
Not on openSUSE.
bor@opensuse:~/build/grub> cat /etc/os-release NAME=openSUSE VERSION="13.2 (Harlequin)" ... bor@opensuse:~/build/grub> chkconfig -A --list | fgrep boot. ... boot.apparmor 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.cycle 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.kdump 0:off 1:off 2:off 3:off 4:off 5:off 6:off boot.udev 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on bor@opensuse:~/build/grub> -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org