Conversation
They all have `Alias=display-manager.service` in the unit file, and having more of them enabled at the same time causes conflicts (for example `systemctl preset` call during installation fails, same as `systemctl preset-all` on release upgrade.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #203 +/- ##
=======================================
Coverage 72.98% 72.98%
=======================================
Files 10 10
Lines 1155 1155
=======================================
Hits 843 843
Misses 312 312 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
@fepitre @HW42 @ben-grande is this change a good idea? I made it just to avoid |
I think that not enabling via preset the login managers by default is better than hiding errors of If they uninstall If we don't want to break user upgrades, makes sense to handle the |
|
The problem is that release upgrade calls So, if calling |
I see now... yes, it should record, but doing that for every release upgrade for every relevant package? What about sshd not being enabled via preset.... It should be documented that user must add preset policies in dom0. For the units that we do know, use ignore directive? |
Mostly ok except it will enable |
Yeah, this still requires handling errors on
No errors on systemctl preset-all
systemctl is-enabled lightdm sddm
> disabled
> enabled |
|
Ok, then |
They all have
Alias=display-manager.servicein the unit file, andhaving more of them enabled at the same time causes conflicts (for
example
systemctl presetcall during installation fails, same assystemctl preset-allon release upgrade.