* Ludwig Nussel <ludwig.nussel@suse.de> [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 -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org