Johannes Meixner wrote:
Assume the old package provided foo.service and foo.socket. In systemd-presets-branding-* only foo.socket was enabled but foo.service was not enabled (I don't know if this makes sense in practice - it is only meant as an example here). Assume the new package only provides foo.service. Then it seems reasonable to change the preset for foo.service to be enabled so that the admin could do "systemctl preset foo" and have the service foo still enabled.
I found an easy way to work-around this limitation and perform one-time initialization when preset is added to file. See my mail in this thread dated Tue, 11 Nov 2014 22:32:32 +0100 I think that it is possible to invent something similar in the branding file: %pre: Check, whether old branding contains preset (or branding contains old version of preset). If not, remember it by touch something un /run. %post: After installation of new preset, call one-time presetting of already existing package. You can check, whether user diverged from the default, and provide smart upgrade path. The package %service_add_post will never do presetting on upgrade. -- 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