Andrei Borzenkov wrote:

В Tue, 11 Nov 2014 17:33:02 +0100 Stanislav Brabec <sbrabec@suse.cz> пишет:

Just like using preset if it is called on update. It will not overwrite current state if it is called only on initial install. The only difference between preset and enable is where decision comes from.

Imagine preset like a way to implement "Reset to default" button. Without preset, there can not be "Reset to default".

But somehow I'm not sure I follow the logic. If installed package is not functional without active service, service should be statically enabled. If it is intended to leave decision to enable service to admin, package should be useable without active service.

The question her is not "Activate this service?" but "Activate this service by package preset or branding preset?" Or even better: Where should be the border line between "package is not functional without active service" (and preset should be probably part of the package) and "package activation should be brand-able" (and preset should be probably part of the branding).

...

Package should use presets. Then %service_add_post is sufficient. It does one time set to preset, and on the next update, service will stay in the previous state,

Not because it is preset, but simply because preset is called only on initial install.

Correct. The current implementation %service_add_post does it in smart way only for presets.* If somebody adds "systemctl enable" to %post, then one-shot activation needs to be handled by package maintainer. (*) Well, the smart way works only if the preset is introduced together with the service. Hopefully, there is an easy trick to introduce one-time preset call even if preset is introduced later: 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

If security team has to approve each preset for each package, what advantage shipping them as part of each package has?

Policy change for particular package does not involve change of all existing branding files. (openSUSE distributes just one branding file, but authors of derived products can create their own branding files.) -- 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