When upgrading major KDE versions, such as 3.4 -> 3.5, global settings are not preserved. For the most part, these don't matter, but login manager (KDM) settings are overwritten with defaults and this can result in unwanted stuff happening (user login icons are gone, possible custom scripts in KDM directory are gone, etc). At minimum, a notification to KDM ebuild should be added that the old configuration can be migrated to the new version by using genkdmconfig. However, I don't see too many reasons why KDM ebuild couldn't simply run genkdmconf at the end. Since we're already doing migration for user settings (see bug #40698).
There are technical difficulties in migrating /usr/kde/3.4/share/config/kdm/kdmrc, because the format changed a lot. See also bug 82276. Probably one thing that could be done was migrating the content of /usr/kde/3.4/share/apps/kdm/faces, but maybe it is a bit late now?
That's where the genkdmconf comes in... # genkdmconf --help genkdmconf - generate configuration files for kdm If an older xdm/kdm configuration is found, its config files are "absorbed"; if it lives in the new target directory, its scripts are reused (and possibly modified) as well, otherwise the scripts are ignored and default scripts are installed. options: --in /path/to/new/kdm-config-dir In which directory to put the new configuration. You can use this to support a $(DESTDIR), but not to change the final location of the installation - the paths inside the files are not affected. Default is /usr/kde/3.5/share/config/kdm. --old-xdm /path/to/old/xdm-dir Where to look for the config files of an xdm/older kdm. Default is to scan /etc/X11/kdm, $XLIBDIR/kdm, /etc/X11/xdm, $XLIBDIR/xdm; there in turn look for kdm-config and xdm-config. Note that you possibly need to use --no-old-kde to make this take effect. --old-kde /path/to/old/kde-config-dir Where to look for the kdmrc of an older kdm. Default is to scan /usr/kde/3.5/share/config and {/usr,/usr/local,{/opt,/usr/local}/{kde3,kde,kde2,kde1}}/share/config. --no-old Don't look at older xdm/kdm configurations, just create default config. --no-old-xdm Don't look at older xdm configurations. --no-old-kde Don't look at older kdm configurations. --old-scripts Directly use all scripts from the older xdm/kdm configuration. --no-old-scripts Don't use scripts from the older xdm/kdm configuration even if it lives in the new target directory. --old-confs Directly use all ancillary config files from the older xdm/kdm configuration. This is usually a bad idea. --no-backup Overwrite/delete old config files instead of backing them up. --no-in-notice Don't put the notice about --in being used into the generated README.
True, genkdmconf can help. This can be considered in the future, but for now I think it's better to leave things as they are, considering that generating kdmrc in this way would mean installing a file on the system based on some information extracted from the building host at compile time - a bit fragile at this stage of development and not worth the trouble. We will look forward at kde4 to see how the situation will change.
Then put the status to resolved LATER :)
