Bug 194764 - KDM needs a way to set a default face icon without copying, hardlinking or symlinking the image file
Summary: KDM needs a way to set a default face icon without copying, hardlinking or sy...
Status: RESOLVED UNMAINTAINED
Alias: None
Product: kdm
Classification: Miscellaneous
Component: general (show other bugs)
Version: unspecified
Platform: Fedora RPMs Unspecified
: NOR wishlist
Target Milestone: ---
Assignee: kdm bugs tracker
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-05-31 16:09 UTC by Mary Ellen Foster
Modified: 2018-04-16 20:26 UTC (History)
3 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 Mary Ellen Foster 2009-05-31 16:09:46 UTC
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!
Comment 1 Oswald Buddenhagen 2009-05-31 16:40:27 UTC
well, the bad news for "downstream" is that it *is* a downstream issue.
Comment 2 Kevin Kofler 2009-05-31 16:58:43 UTC
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.
Comment 3 Oswald Buddenhagen 2009-05-31 17:11:15 UTC
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.
Comment 4 Kevin Kofler 2009-05-31 17:16:16 UTC
> 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.
Comment 5 Kevin Kofler 2009-05-31 17:17:25 UTC
Reformulating as a wish as you asked.
Comment 6 Oswald Buddenhagen 2009-05-31 17:28:46 UTC
(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.
Comment 7 Kevin Kofler 2009-05-31 17:31:01 UTC
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.
Comment 8 Kevin Kofler 2009-05-31 17:34:30 UTC
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).
Comment 9 Oswald Buddenhagen 2009-05-31 17:50:43 UTC
(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.
Comment 10 Kevin Kofler 2009-05-31 17:54:11 UTC
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.
Comment 11 Maciej Mrozowski 2010-06-23 02:53:21 UTC
/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.
Comment 12 Nate Graham 2018-04-16 20:26:44 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/