SUMMARY Using the KCM SDDM module, and attempting to configure SDDM from System Settings, such as for example changing the background to an existing theme, results in a password prompt, followed by KCM writing to the configuration file: /usr/share/sddm/themes/debian-breeze/theme.conf.user /usr is clearly not the right place to save runtime configuration data, and theme.conf.user does not belong there. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Debian Unstable (linux 6.12.13) KDE Plasma Version: 6.3.0 KDE Frameworks Version: 6.10.0 Qt Version: 6.7.2
This was initially reported in Debian as bug https://bugs.kde.org/show_bug.cgi?id=500151
Hem, that should read bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1090041
That's where SDDM expects the file to be. Where else would it be? SDDM runs outside of the regular user, so it can't be in the current user's home
(In reply to Nicolas Fella from comment #3) > That's where SDDM expects the file to be. Where else would it be? SDDM runs > outside of the regular user, so it can't be in the current user's home That violates the Filesystem Hierarchy Standard specification. See : https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s11.html https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s07.html Host-specific configuration belongs to /etc whereas /usr/share is meant to be readonly and shareable between hosts. If that’s a feature of SDDM it should probably be rewritten to use configuration in /etc instead.
>If that’s a feature of SDDM it should probably be rewritten to use configuration in /etc instead. It should. Still needs SDDM to change first.
If that's how it works now, removing it from Debian (testing/trixie) isn't really going to help anyone. I.e. Debian should keep it with current (not formally compliant) behavior and wait for upstream to fix it.
Uh no it’s not going into trixie. The bug was reported in Debian as release critical (policy violation) and I agree with the qualification. Maybe it doesn’t help you but it’s very useful to many to know that /usr/share is not changing under them outside package manager operations. And we’re not talking about some MUST feature that you cannot live without. You can either live with the default SDDM greeter or edit the configuration in /etc/sddm.conf.d/kde_settings.conf.
It does this since forever, not sure why this is suddently critical.
True. It has been noticed only recently. And the issue is only with the theme customizer. The theme switcher correctly writes to /etc.
Background can only be chanched by writing into usr / the theme directory. That's how sddm works.
Yes yes, I got that, and TTBOMK it’s an incorrect design. I don’t have the knowledge or bandwidth to fix it myself though. The best I could probably do is to patch out the theme editing part so it fixes the policy violation and we can ship sddm-kcm again.
Its quite unfortubte, especially for those using custom color palettes, because now all of that bit would have to be applied manually in Debian. I agree with the sentiment about /usr/share not being messed with, but that doesn't change the fact that the timing is unfortunate, being so close to the freeze. (In reply to Aurélien COUDERC from comment #4) > If that’s a feature of SDDM it should probably be rewritten to use > configuration in /etc instead. Has anyone raised this issue to upstream SDDM yet? That might be a good next move
> It should. Still needs SDDM to change first. https://github.com/sddm/sddm/issues/1561 and https://github.com/sddm/sddm/pull/1739 seem to be relevant here. From there it's evident that perhaps we are in a bit of a chicken-and-egg situation, as (I believe) one of the sddm maintainers mentions in that PR: "KDE Plasma's sddm-kcm hardcodes /usr/share/sddm/themes, which is the issue here.". FHS violations are major/serious bugs across pretty much all distributions, and are even more pronounced on immutable /usr ones. I appreciate that this sounds a little sudden and the the urgency of this feels a little arbitrary, though! It'd be awesome if sddm/sddm-kcm maintainers agreed on the path forward regardless of the timeline and even if they don't make it into a stable release immediately. I'm sure distros would appreciate it and perhaps could even backport the fixes. Debian's freeze timeline is a good impetus of course :) (I'm the original bug reporter on the Debian side but not involved with maintaining sddm/KDE in Debian)
Possibly relevant passage: https://github.com/sddm/sddm/wiki/Theming If I'm read:ng this right, it means that a theme config does NOT have to be in the same directory as the theme itseof, but the theme has to specify this. Perhaps its time to make puttng theme configs under /etc the norm?
Then this should relatively easy at least for breeze theme? As we control both sides.
Actually not, it is relative to theme dir https://github.com/sddm/sddm/blob/c2b97dd63f726fa3db7f699bb40b2be3e62b8df5/src/greeter/GreeterApp.cpp#L109
(In reply to John Faulk from comment #14) > Perhaps its time to make puttng theme configs under /etc the norm? To add a little bit of extra complexity to it: theme configs can be under /etc, if they're meant for the administrator to edit by hand. For configuration that another component would/could write to, such as KCM, /var/lib would be the appropriate path. HTH!