On Nov 24, 2014 v at 14:08 Ludwig Nussel wrote:
Stanislav Brabec schrieb:
Optional packages should be working properly out of the box. If the service is socket activated, its running needs no configuration, and it's secure to turn it on, we should do setup on packaging level. Especially if admin already enabled them, update should not break it.
I agree but the way to turn on things is the preset mechanism.
Yes. I still talk about presets. I am just thinking about the proper package for presets for packages, which are "apparently broken" if the preset is set differently. Does it make sense to add such packages to the distro-wide preset file, or does it make sense to distribute the preset together with such package?
I think that these cases should be handled by packagers, not macro authors.
rpm scripts are fragile by nature. The more we can do in a generic way where the individual packager doesn't have to care the better.
I agree. Standard macros handle standard upgrade process correctly (i. e. read sysvinit script state, remember it, use it in case of upgrade, otherwise use preset just for one time setup). But if macros were not used correctly, then The Bad Thing already happened. Macro authors cannot cover the whole range of Bad Things. Package maintainer should find a fix, as only the package maintainer knows, what was done incorrectly in the previous version.
Preset introduced later than the service, and you need one time preset:
%pre ... if [ $1 -gt 1 ] ; then if ! {test if preset exists in file or branding file} ; then echo -n "" >/run/rpm-%{name}-update-{service name}-new-in-upgrade fi fi
See also the discussion on the systemd list: http://lists.freedesktop.org/archives/systemd-devel/2014-November/025363.htm...
It's perfectly fine for us to change the default enable state of a service. However the package should not make guesses whether the previous (disabled) state was because of the distro default or a conscious decision of the admin. IOW don't do that :-)
Well. The Bad Thing already happened: Package was installed without any prefix, resulting in the bad default state for everybody who did the upgrade. Even worse, we cannot discriminate between conscious decision of the admin to stop the service and misbehavior introduced by the previous incorrect package upgrade. We have only two chances: - Keep it broken forever to everybody except conscious admins. - Ignore the current service state and set it to the default. The work around above does the second, and it does it only once while introducing preset and never more. IMHO it is the least pain possible.
That's what systemd-sysv-convert is supposed to do automatically, right? If it doesn't do it for some reason it's most likely a bug that needs to be fixed in systemd-sysv-convert.
I this case the script in the package is superfluous. -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz Lihovarská 1060/12 tel: +49 911 7405384547 190 00 Praha 9 fax: +420 284 084 001 Czech Republic http://www.suse.cz/ PGP: 830B 40D5 9E05 35D8 5E27 6FA3 717C 209F A04F CD76 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org