On Fri, Jan 21, 2000 at 01:50:48PM +1100, Brian May wrote:
> >>>>> "Martin" == Martin Waitz <martin@rommel.stw.uni-erlangen.de> writes:
>
> Martin> hi, i just noticed the new gdm conflicting with (amoung
> Martin> others) xdm.
>
> Not good.
Just to get everyone on debian-devel up to speed on this issue:
You will regret it very much if you get more than one process fighting over
control of a particular virtual console. getty uses /etc/inittab to
determine what VC's it should place login prompts on; xdm uses
/etc/X11/xdm/Xservers. The other display managers we package use some
conffile of their own, I imagine.
[Actually, it's not the display managers themselves that occupy a VC, but
the X server they launch to present their greeter screen...if you're
running a display manager that manages only remote sessions, you don't have
to worry about this problem.]
In short, the console can get locked (hard) if two display managers both
want the same VC, or if a display manager and getty both want the same VC.
We had outstanding bugs for years about this. My imperfect solution was to
hard code VC 7 into /etc/X11/xdm/Xservers for the only X server launched.
This corresponds to the fact that the default /etc/inittab (which is in a
package I don't maintain) only launches gettys on VC's 1 through 6. If you
don't instruct xdm to tell the X server to start on a particular VC, then
getty and xdm can race for possession of, say, VC 2 and you get a lock.
Fooling with the digits in the rc.d links did nothing to fix this.
> Martin> on the other hand task-x-window-system depends on xdm.
>
> Martin> i would like to keep both gdm and task-x-window-system.
> Martin> task-x-window-system should depend on an virtual package
> Martin> (something like display-manager), provided by {x,g,k}dm.
Don't forget wdm.
> Martin> should i file wishlist-bugs against these packages? what
> Martin> do you think would be best?
>
> I sent a bug against task-x-window-system, with a solution, but not
> sure I could convince the maintainer.
>
> Sorry, I can't give you the bug number, bugs.debian.org seems to be
> down right now.
It's in the Cc line of this mail.
I am closing this bug because the task-x-window-system package is for
novice users who want what is described in its package description. (Note
that task-x-window-system-core does what an older version of
task-x-window-system does.)
I suggest that the other display managers be made part of different tasks.
gdm can be made part of some kind of gnome task.
kdm can be made part of some kind of KDE task -- assuming we can ship a
meaningful KDE task.
wdm can be made part of some Window Maker or otherwise NeXTish task.
Each of the above tasks can and should depend on task-x-window-system-core
to bring in the essential pieces of the X Window System. The -core task
does *NOT* contain xdm.
I furthermore agree with the sentiment, expressed in a recent mail to this
list, that the task packages are made deliberately simplistic for the sake
of newcomers to Debian, and/or people who might be daunted by the number of
packages we provide. They are not really designed for experienced users or
package maintainers. Let us not migrate the complex web of
conflicts/replaces/provides in our real packages to the tasks, please.
They are a limited tool for a limited purpose.
Finally, yes, there may be a better solution. The real problem is that we
don't have a central repository for VC allocation data. If we do, then we
can solve this problem, but it will probably mean /etc/inittab,
/etc/X11/xdm/Xservers, and whatever the other display managers use to
decide when to launch X servers will lose their conffile status and will
have to be autogenerated. I think it is part of Debian's philosophy that
the knowlegeable admin should be able to go into /etc and start hacking
away, and not have to know about distribution-specific piles of "real"
config files that will overwrite his customizations at a whim (*cough*
/etc/sysconfig *cough*). The VC allocation issue is a big deal since it
can lock the console. But we need to be very careful how we go about
solving it.
--
G. Branden Robinson | One man's "magic" is another man's
Debian GNU/Linux | engineering. "Supernatural" is a
branden@ecn.purdue.edu | null word.
roger.ecn.purdue.edu/~branden/ | -- Robert Heinlein
Attachment:
pgpL2SnqZ218c.pgp
Description: PGP signature