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@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx > > To unsubscribe send an email to devel-announce-leave@xxxxxxxxxxxxxxxxxxxxxxx > > 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@xxxxxxxxxxxxxxxxxxxxxxx > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > 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@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
