Please add release notes to the release notes section so that this may be sent to fesco. I disagree that there is not a need to mention; there is plenty of information in the Benefit to Fedora section that would be useful in release notes, and would ensure that the feature would actually be known about and get used by community members within Fedora, at the bare minimum.--Rbergero 13:06, 14 November 2011 (UTC)
... I still need release notes in the release notes section :) --Rbergero 18:05, 12 December 2011 (UTC)
- There's nothing really to announce in the release documents as long as not a substantial number of packages have been converted to use the scriptlets. It's initially a useless feature for users. But this feature needs to be accepted so that it is clear to Fedora developers that it is time to make use of this.--Lennart 21:22, 20 July 2012 (UTC)
I can't see why Fedora would want a presets feature that works for 5% of the packages. Support in systemd can obviously go in any time, but when the packaging guidelines change, all existing scriptlets need to be converted within a single release (... and this probably means finding some provenpackagers willing to do ~50% of the work). -- Mitr 16:21, 16 December 2011 (UTC)
- Highlighting this concern just to be sure it was noticed by feature owners - I haven't seen any response, neither in December nor recently.
- This feature is about getting the backing from FESCO for presets and get the infrastructure in, but the adoption of the new scriptlets is something that can happen over time. --Lennart 21:22, 20 July 2012 (UTC)
Putting the presets into fedora-release creates centralizes information that really doesn't need to be centralized and adds another bottleneck. I think it would make more sense for Fedora if (systemctl preset FOO.service) checked the presets, and defaulted to state described somewhere inside the PRM package (presumably in the unit file) - so that the default preset configuration could be empty. -- Mitr 16:21, 16 December 2011 (UTC)
- The entire goal here is to separate the mechanism from the policy and split the default install state out of the packages, because the packages should not encode policy on their own. It should be up to the distro, the spin or the admin whether a service is enabled by default or not, but not to the individual package developer. --Lennart 21:22, 20 July 2012 (UTC)
I think the macros need to be approved by the FPC (obviously), and they should probably be discussed with RPM developers (they are working on a different mechanism for common scriptlets, and doing the migration twice is just unnecessary work). -- Mitr 16:21, 16 December 2011 (UTC)
- FPC is positive on the macros, but wants FESCO to accept the feature first, see https://fedorahosted.org/fpc/ticket/190 for details. --Lennart 21:22, 20 July 2012 (UTC)
As a minor comment, from a semantics point of view, it's not always quite clear what is the "Fedora default" - e.g. when I enable NTP in firstboot, and it runs (systemctl enable chronyd.service), is the "Fedora default" off or on? -- Mitr 16:21, 16 December 2011 (UTC)
- The fedora default is what is listed here: https://fedoraproject.org/wiki/Starting_services_by_default --Lennart 21:22, 20 July 2012 (UTC)
I guess for approval of this feature, we are missing discussion with rpm people and FPC agreement. -- mmaslano 17:53, 10 January
- FPC is positive, see https://fedorahosted.org/fpc/ticket/190 but wants FESCO to accept this --Lennart 21:22, 20 July 2012 (UTC)