https://fedoraproject.org/wiki/Changes/Systemd_presets_for_user_units
== Summary ==
System units are managed through presets [https://fedoraproject.org/wiki/Features/PackagePresets since F18] and by policy, presets are carried by the fedora-release package. This policy is now extended to user units.
== Owner == * Name: [[User:zbyszek| Zbigniew Jędrzejewski-Szmek]] * Email: zbyszek at in waw pl
== Detailed Description ==
The preset mechanism for user units was already in place, but we were missing the actual preset files, and the default was "enable *" instead of "disable *" as for system services.
Systemd will now provide a /usr/lib/systemd/user-preset/99-default-disable.preset that marks user services as disabled by default. Any user services which should be enabled will be to get an appropriate preset in /usr/lib/systemd/user-preset/90-default-user.preset or a spin-specific file. Most packages already call into the preset mechanism, but those which don't will be adjusted to do that.
This is essentially a fix for https://bugzilla.redhat.com/show_bug.cgi?id=1468501. There is no good reason to treat user services different than system services in this regard. On the systemd side this change is very simple, but all packages that provide user units need to be reviewed to check if they are enabled after the change if appropriate.
== Benefit to Fedora ==
User and system services are handled in the same way.
Local configuration may be used to override which services should be enabled after upgrade. In particular, "local" in this context may mean "per-spin" or "per-user".
== Scope == * Proposal owners: ** review all packages that provide user services in Fedora and submit PRs when changes are needed ** add a new presets file to the fedora-release package for user units ** submit a proposal to FPC to update the guidelines (essentially to say "... and the same for user services.").
* Other developers: ** FPC: review (and accept ;)) the guidelines changes ** other maintainers: verify that units in their packages are enabled or not as appropriate after package installation
* Release engineering: n/a
* Policies and guidelines: a pull request will be submitted
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact == Should not be user visible. Some units which are are currently enabled by mistake will not be enabled anymore on new installations.
== How To Test == Install a new system (or uninstall and reinstall some packages). Verify that the appropriate units are enabled for the user session.
== User Experience == N/A
== Dependencies == N/A
== Contingency Plan ==
* Contingency mechanism: Revert the changes.
* Contingency deadline: beta freeze * Blocks release? No * Blocks product? No
== Documentation == A pull request for the packaging guidelines will be submitted.
== Release Notes == Not needed.
Do we have list of affected packages / services? I'd be more comfortable if we would have list of these and explicitly enabled mandatory ones so that we don't break composes and such.
On Thu, Jan 2, 2020 at 4:15 PM Ben Cotton bcotton@redhat.com wrote:
https://fedoraproject.org/wiki/Changes/Systemd_presets_for_user_units
== Summary ==
System units are managed through presets [https://fedoraproject.org/wiki/Features/PackagePresets since F18] and by policy, presets are carried by the fedora-release package. This policy is now extended to user units.
== Owner ==
- Name: [[User:zbyszek| Zbigniew Jędrzejewski-Szmek]]
- Email: zbyszek at in waw pl
== Detailed Description ==
The preset mechanism for user units was already in place, but we were missing the actual preset files, and the default was "enable *" instead of "disable *" as for system services.
Systemd will now provide a /usr/lib/systemd/user-preset/99-default-disable.preset that marks user services as disabled by default. Any user services which should be enabled will be to get an appropriate preset in /usr/lib/systemd/user-preset/90-default-user.preset or a spin-specific file. Most packages already call into the preset mechanism, but those which don't will be adjusted to do that.
This is essentially a fix for https://bugzilla.redhat.com/show_bug.cgi?id=1468501. There is no good reason to treat user services different than system services in this regard. On the systemd side this change is very simple, but all packages that provide user units need to be reviewed to check if they are enabled after the change if appropriate.
== Benefit to Fedora ==
User and system services are handled in the same way.
Local configuration may be used to override which services should be enabled after upgrade. In particular, "local" in this context may mean "per-spin" or "per-user".
== Scope ==
- Proposal owners:
** review all packages that provide user services in Fedora and submit PRs when changes are needed ** add a new presets file to the fedora-release package for user units ** submit a proposal to FPC to update the guidelines (essentially to say "... and the same for user services.").
- Other developers:
** FPC: review (and accept ;)) the guidelines changes ** other maintainers: verify that units in their packages are enabled or not as appropriate after package installation
Release engineering: n/a
Policies and guidelines: a pull request will be submitted
Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact == Should not be user visible. Some units which are are currently enabled by mistake will not be enabled anymore on new installations.
== How To Test == Install a new system (or uninstall and reinstall some packages). Verify that the appropriate units are enabled for the user session.
== User Experience == N/A
== Dependencies == N/A
== Contingency Plan ==
Contingency mechanism: Revert the changes.
Contingency deadline: beta freeze
Blocks release? No
Blocks product? No
== Documentation == A pull request for the packaging guidelines will be submitted.
== Release Notes == Not needed.
-- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis _______________________________________________ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedorapro...
On Thu, Jan 02, 2020 at 04:22:41PM +0100, Igor Gnatenko wrote:
Do we have list of affected packages / services? I'd be more comfortable if we would have list of these and explicitly enabled mandatory ones so that we don't break composes and such.
Yes ... and no. I made a list a few months back, but I can't find it :( It'd need updating anyway. I'll try to post an up-to-date list sometime next week after I'm back from vacation.
Zbyszek
On Thu, Jan 2, 2020 at 4:15 PM Ben Cotton bcotton@redhat.com wrote:
https://fedoraproject.org/wiki/Changes/Systemd_presets_for_user_units
== Summary ==
System units are managed through presets [https://fedoraproject.org/wiki/Features/PackagePresets since F18] and by policy, presets are carried by the fedora-release package. This policy is now extended to user units.
== Owner ==
- Name: [[User:zbyszek| Zbigniew Jędrzejewski-Szmek]]
- Email: zbyszek at in waw pl
== Detailed Description ==
The preset mechanism for user units was already in place, but we were missing the actual preset files, and the default was "enable *" instead of "disable *" as for system services.
Systemd will now provide a /usr/lib/systemd/user-preset/99-default-disable.preset that marks user services as disabled by default. Any user services which should be enabled will be to get an appropriate preset in /usr/lib/systemd/user-preset/90-default-user.preset or a spin-specific file. Most packages already call into the preset mechanism, but those which don't will be adjusted to do that.
This is essentially a fix for https://bugzilla.redhat.com/show_bug.cgi?id=1468501. There is no good reason to treat user services different than system services in this regard. On the systemd side this change is very simple, but all packages that provide user units need to be reviewed to check if they are enabled after the change if appropriate.
== Benefit to Fedora ==
User and system services are handled in the same way.
Local configuration may be used to override which services should be enabled after upgrade. In particular, "local" in this context may mean "per-spin" or "per-user".
== Scope ==
- Proposal owners:
** review all packages that provide user services in Fedora and submit PRs when changes are needed ** add a new presets file to the fedora-release package for user units ** submit a proposal to FPC to update the guidelines (essentially to say "... and the same for user services.").
- Other developers:
** FPC: review (and accept ;)) the guidelines changes ** other maintainers: verify that units in their packages are enabled or not as appropriate after package installation
Release engineering: n/a
Policies and guidelines: a pull request will be submitted
Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact == Should not be user visible. Some units which are are currently enabled by mistake will not be enabled anymore on new installations.
== How To Test == Install a new system (or uninstall and reinstall some packages). Verify that the appropriate units are enabled for the user session.
== User Experience == N/A
== Dependencies == N/A
== Contingency Plan ==
Contingency mechanism: Revert the changes.
Contingency deadline: beta freeze
Blocks release? No
Blocks product? No
== Documentation == A pull request for the packaging guidelines will be submitted.
== Release Notes == Not needed.
-- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis _______________________________________________ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedorapro...
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org