Version: (using KDE 4.2.3) Installed from: Fedora RPMs (This issue was originally reported downstream at Fedora -- https://bugzilla.redhat.com/502618 -- and I was advised to report it here instead ...) It seems impossible to make kdm remember any default user icon other than the (IMHO) incredibly ugly icon in /usr/share/kde4/apps/kdm/pics/users/default1.png. Even if I change it in the configuration, reinstalling kdm is enough to return it to the original. Steps to Reproduce: 1. Open the KDM configuration (System Settings - Advanced - Login Manager) 2. Go to the "Users" tab 3. Select some other default icon (e.g., /usr/share/kde4/apps/kdm/pics/users/default_leonidas.png) 4. Save and quit -- the new icon is in place 5. "yum reinstall kdm" (or install a new version if it's available) 6. Check the configuration now -- the icon is back to default1.png again!
well, the bad news for "downstream" is that it *is* a downstream issue.
The symlink for the default icon is created in the kdm package. So it's normal that this is reset each time the package is reinstalled. Upstream needs a way to configure the icon without setting symlinks in systemwide directories, there's currently no way to both have a system default and let the user override it. Why is this not set in kdmrc instead? RPM has mechanisms for keeping user-modified config files, but not for keeping user-modified symlinks. The bug on our (Fedora's) end is that we're still using default1.png instead of default_leonidas.png as we should as the default on F11, we'll be fixing that one. But it doesn't fix the underlying issue, which IS an upstream issue.
uhm, no. ;) for one, kdm does *not* create any symlinks. that's *your* stuff. second, it isn't the task of upstream to adapt to the limitations of downstream. ;) it was a conscious decision to save user images as actual copies (primarily to make user choices survive upstream changes). optional alternatives are being considered, but that's a wishlist item (it's in the TODO file; you may create a report if there is none yet). for the time being, just treat everything under $prefix/share/apps/kdm/faces/ as config files.
> second, it isn't the task of upstream to adapt to the limitations of > downstream. ;) Uh, making KDE actually work properly when packaged IS your task. The vast majority of your users will be using some package. End users don't build software from source. > it was a conscious decision to save user images as actual copies Copies aren't any better than symlinks for this. In fact, if we put a copy instead of a symlink as default.png, it will be just as broken. > (primarily to make user choices survive upstream changes). While that's a valid reason, it means we have no way to set a default without making user choices survive nothing at all, not even a simple rebuild of the package. > optional alternatives are being considered, but that's a wishlist item (it's in > the TODO file; you may create a report if there is none yet). > for the time being, just treat everything under $prefix/share/apps/kdm/faces/ > as config files. Config files under /usr/share violate the FHS and are not allowed by our packaging guidelines. And treating an image file as a config file sounds just plain wrong to me.
Reformulating as a wish as you asked.
(In reply to comment #4) > > second, it isn't the task of upstream to adapt to the limitations of > > downstream. ;) > > Uh, making KDE actually work properly when packaged IS your task. > i would accept that if you came up with an even remotely convincing argument why it is inherently impossible to deal with kdm's current way downstream. as is, i can see only problems of your current packaging tool and/or policy. > > (primarily to make user choices survive upstream changes). > > While that's a valid reason, it means we have no way to set a default without > making user choices survive nothing at all, not even a simple rebuild of the > package. > again your problem. upstream kde handles this by calling genkdmconf which does the right things. you are supposed to do that as well. > > for the time being, just treat everything under $prefix/share/apps/kdm/faces/ > > as config files. > > Config files under /usr/share violate the FHS and are not allowed by our > packaging guidelines. And treating an image file as a config file sounds just > plain wrong to me. > well, then treat it as application data and put it under /var/lib/kdm/faces or so. in fact, i should do that upstream ... good patches welcome.
Unfortunately, I think having files marked %config under anything other than /etc will be frowned upon. And %config is the only way the file will not get overwritten with the default.
By my understanding of the FHS, I think the current place under /usr/share is the correct place to store the available images (default[123].png) as those are not intended to be modified. The chosen default needs (again, according to the FHS as I understand it) to be set somewhere under /etc (preferably under /etc/kde/kdm).
(In reply to comment #7) > that's why you are supposed to use genkdmconf. ;-) (In reply to comment #8) > The chosen default needs (again, according to the > FHS as I understand it) to be set somewhere under /etc (preferably under > /etc/kde/kdm). > yes, but that again puts binaries in a config dir. how do other packages deal with that? take the package database of rpm itself, the lease cache of dhcpd3 - anything.
Those are both under /var, but they don't come with a packaged default: * The RPM database is kinda special, it is not owned by a package (chicken&egg) and it is created during installation of the system. * AFAIK, the DCHP lease cache gets created the first time it's needed.
/usr/share/ being writable is unacceptable and setting FaceDir= seems not to work (last tested with kdm from KDE SC 4.4.4) - /usr/share/apps/kdm/faces is created nevertheless.
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/