Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 114530 - KDM settings should be preserved when upgrading major KDE versions
Summary: KDM settings should be preserved when upgrading major KDE versions
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] KDE (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Gentoo KDE team
Depends on:
Reported: 2005-12-05 06:09 UTC by Antti Mäkelä
Modified: 2006-06-03 08:22 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Antti Mäkelä 2005-12-05 06:09:02 UTC
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).
Comment 1 Gregorio Guidi (RETIRED) gentoo-dev 2006-05-31 11:12:29 UTC
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?
Comment 2 Antti Mäkelä 2006-05-31 13:45:24 UTC
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

  --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
    Don't look at older xdm/kdm configurations, just create default config.
    Don't look at older xdm configurations.
    Don't look at older kdm configurations.
    Directly use all scripts from the older xdm/kdm configuration.
    Don't use scripts from the older xdm/kdm configuration even if it lives
    in the new target directory.
    Directly use all ancillary config files from the older xdm/kdm
    configuration. This is usually a bad idea.
    Overwrite/delete old config files instead of backing them up.
    Don't put the notice about --in being used into the generated README.
Comment 3 Gregorio Guidi (RETIRED) gentoo-dev 2006-06-03 07:03:12 UTC
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.
Comment 4 Antti Mäkelä 2006-06-03 08:22:35 UTC
Then put the status to resolved LATER :)