Bug 300997 - Installing config files to /usr/share/config violates Filesystem Hierarchy Standard
Summary: Installing config files to /usr/share/config violates Filesystem Hierarchy St...
Status: RESOLVED UNMAINTAINED
Alias: None
Product: kdm
Classification: Miscellaneous
Component: general (show other bugs)
Version: unspecified
Platform: unspecified Linux
: NOR minor
Target Milestone: ---
Assignee: kdm bugs tracker
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-06-01 14:25 UTC by Florian Petran
Modified: 2018-04-16 20:23 UTC (History)
6 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Florian Petran 2012-06-01 14:25:21 UTC
Currently, KDE products install their config files to /usr/share/config, but this violates the Filesystem Hierarchy Standard. It states (p.18):
"/usr is shareable, read-only data. That means that /usr
should be shareable between various FHS-compliant hosts and must not be written to. Any information that is host-specific or varies with time is stored elsewhere." [1]

And on p. 22:
"The /usr/share hierarchy is for all read-only architecture independent data files.This hierarchy is intended to be shareable among all architecture platforms of a given OS; thus, for example, a site with i386, Alpha, and PPC platforms might maintain a single /usr/share directory that is centrally-mounted. [...] Any program or package which contains or requires data that doesn’t need to be modified should store that data in /usr/share (or /usr/local/share, if installed locally)." [1]

Since config files make only sense when they are occasionally written to, it is a violation of the FHS to keep them under /usr or /usr/share. I propose that the config files be moved to a subdirectory under /etc like /etc/kde.

[1] http://refspecs.linuxfoundation.org/FHS_2.3/fhs-2.3.pdf

Reproducible: Always




Seen in KDE 4.8 but AFAIK applies to current git as well. Checked Linux under OS, but it applies to all OS that honor FHS, such as the *BSDs.
Comment 1 Christoph Feck 2012-06-01 14:47:43 UTC
Can you be more specific which of those files is actually written to? The changed configuration is stored into the user's home directory, so the files in /usr should never be written to.
Comment 2 Florian Petran 2012-06-01 14:52:46 UTC
Well I haven't done a comprehensive survey, but at least the Xdmcp part of /usr/share/config/kdm/kdmrc can't be stored on a per-user basis.

Also, if the admin wants to modify default settings system-wide it will be overwritten on update.
Comment 3 Christoph Feck 2012-06-01 15:30:23 UTC
Yes, kdm is special, see related discussion at bug 194764.

Regarding the other configuration files, administrators usually setup a /etc/skel directory, where defaults are stored. This is the case with openSUSE I am using, but it will be applied only for new users. I don't know if it is wise to change defaults for existing users, they might get confused.

I am reassigning this to kdm developers. If you find more places, where KDE actually modifies the files in /usr, please file separate reports.
Comment 4 Kevin Kofler 2012-10-26 15:24:00 UTC
> Regarding the other configuration files, administrators usually setup a /etc/skel directory, where
> defaults are stored. This is the case with openSUSE I am using, but it will be applied only for new
> users. I don't know if it is wise to change defaults for existing users, they might get confused.

Fedora supports /etc/kde for this (which takes priority over both the default profile shipped by the Fedora kde-settings package and the upstream defaults in /usr/share/config) using this patch:
http://pkgs.fedoraproject.org/cgit/kdelibs.git/tree/kdelibs-4.6.90-kstandarddirs.patch
(second hunk, the first one is one of the changes required to make LIBEXEC_INSTALL_DIR=/usr/libexec/kde4 work properly).
Comment 5 Florian Petran 2012-11-19 15:09:17 UTC
There hasn't been much of a reaction on this from the devs so far. Can we expect something like the Fedora patch Kevin posted to be merged any time soon, or at all? Are any of the KDM developers working on a possible KDM specific fix of this issue? Can we get some sort of statement on this?
Comment 6 Nate Graham 2018-04-16 20:23:24 UTC
KDM is unmaintained and not used in KDE Plasma 5.

SDDM is the login manager used in KDE Plasma 5. If you still have this same issue with SDDM, please file an issue on the SDDM bugtracker (after doing a search for existing issues first!): https://github.com/sddm/sddm/issues/