[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

kde & update-alternatives

>From scanning the archives of this list and debian-user, this seems to be a problem that other people have had in the  past, but the *right*
way to solve this still isn't clear to me.

First, I'm using Potato (2.2r5).

I already had XDM & WinowMaker installed & working (if you can call it that) after my initial install. I got the kde packages  from kde.debian.net.
After a seemingly succesful install with dselect, I come up in KDM at boot/login but I still go into WindowMaker after login.

When I run:
update-alternatives --config x-window-manager

I have no choice there for anything related to KDE. Reading /usr/doc/kdebase/README.Debian suggests  that there
should be something there.

Now, the discussion on this list in the past has seemed to suggest there may just be some inherent  incompatabilities
between the way kde treets it's environment and the assumptions about X made by the update- alternatives system, at least
in potato anyway, and the only way to deal with it is to hack around it. (Is that right?)

Hack or not, here's the options that I see. Some from this list some from my own pondering...

1) edit file /etc/kde2/kdrmc, an add kde2 to line saying
SessionTypes=default,failsafe, so that it looks like

or the same idea but through kcontrol

This seems to bypass the update alternatives mechanism and connect the KDE session directly from KDM.

2) either
cd /etc/alternatives
ln -s /usr/bin/startkde x-window-manager
update-alternatives --install /usr/bin/x-window-manager x-window-manager /usr/bin/startkde <high  priority>
update-alternatives --install /usr/bin/x-window-manager x-window-manager /usr/bin/kde2 <high priority>

Will either of these even work?

update-alternatives --install /usr/bin/x-session-manager x-session-manager /usr/bin/startkde <high  priority>
I belive that KDM is showing up as my x-session-manager & it seems to me that this is what I want.

~/.xsession == exec startkde
~/.xsession == exec kde2
(Do either of these work? If so are there any drawbacks to this approach?)

Use woody instead.
It's not clear that this solves the problem though. It sounds like it's not exactly airtight in woody  either.

So... I just want to know if there is an accepted "best", or *safest*, or at least *conventional* way  to solve this problem.

It seems like #1 is the way KDM wants you to solve the problem. It sounds like this works too. Is this what most people do? Do any of the 
methods using the update-alternatives mechanism even work? Is there anyone, developers maybe, out there who can comment about the 
apparent disconnect between the altenatives system and KDE? Is it a never the twain shall meet kinda thing? Is there a FAQ that I missed?

Reply to: