Offer a way to override default config via /usr/share/sddm/config.d

[shadeslayer]

From a downstream perspective, when shipping multiple themes, it would be awesome to have themes install a config file to /usr/share/sddm/config.d to override the default theme from /etc/sddm.conf

Alternatively, maybe implementing a fall back mechanism would make sense as well. For eg. Try to load theme from /etc/sddm.conf , if theme doesn't exist check /usr/share/sddm/conf.d

[jriddell]

This is needed to make nvidia-prime support elegant
#393

[plfiorini]

👍 except for minor details regarding the location

I would follow the systemd convention here so SDDM should:

• Load /etc/sddm.conf (for compatibility - to be dropped after a few releases after this stuff gets implemented)
• Load /etc/sddm/sddm.conf (new main config file name)
• Load /usr/lib/sddm/sddm.conf.d/*.conf sorting in alphabetical order
• Load /etc/sddm/sddm.conf.d/*.conf sorting in alphabetical order

/etc/sddm/sddm.conf.d/*.conf is where the system administrator puts his stuff
/usr/lib/sddm/sddm.conf.d/*.conf is where the distro puts its stuff

[majewsky]

I think the last one in your list should be /etc/sddm/sddm.conf.d/*.conf. The convention is to append .d/*.conf to the filename of the singular config file, in this case /etc/sddm/sddm.conf.

Compare, for example, /etc/systemd/journald.conf and /etc/systemd/journald.conf.d/*.conf.

[plfiorini]

Fixed thanks, it was a typo

[jleclanche]

@plfiorini We could do it like supervisor does it:

[include]
files = /etc/supervisor.d/*.ini

[jleclanche]

@plfiorini btw this would take backwards compatibility out of our hands and into the distros', then :)

[plfiorini]

@jleclanche i'd like to have more predictable file locations and copy the systemd pattern because it is likely to be more familiar to our user base

[jleclanche]

@plfiorini with an include directive, we could do whatever we want.

[majewsky]

Indeed, but what's the added value compared to the cost of inconsistency between distributions?

[jleclanche]

Frankly sddm's not here to solve how inconsistent distros are between each other.

[majewsky]

Yes, but there's no need to add insult to injury when there is no actual usecase for a generic include syntax.

[jleclanche]

Huh? There's a use case right there, we don't get to worry about backwards compatibility and we're as flexible as distros want.

[majewsky]

Which use-case? When will distros ever need anything beyond /usr/share/sddm.conf.d/*.conf?

[jleclanche]

Implementing these paths is not cheap, it's a maintenance burden and a promise of forward compatibility. An include directive means we don't worry about this.

[majewsky]

How do you see any maintenance burden involved in writing three or four paths into the code and calling it a day? It's not like the FHS changes every other day.

[lbssousa]

If/When SDDM gains support for those config drop-ins, it would be easier to address item 4 of issue #78 (provide per-seat settings in sddm.conf), specially if second approach proposed there becomes the prefered one.

[shadeslayer]

Hi
Is there any ETA on this? IMO the maintainer should just pick one approach and call it a day.

[plfiorini]

@shadeslayer Right, it should be this way:

• Load /etc/sddm.conf (for compatibility - to be dropped after a few releases after this stuff gets implemented)
• Load /etc/sddm/sddm.conf (new main config file name)
• Load /usr/lib/sddm/sddm.conf.d/*.conf sorting in alphabetical order
• Load /etc/sddm/sddm.conf.d/*.conf sorting in alphabetical order

/etc/sddm/sddm.conf.d/*.conf is where the system administrator puts his stuff
/usr/lib/sddm/sddm.conf.d/*.conf is where the distro puts its stuff

It's an established convention, plus a factory reset would still provide good defaults from the vendor