Re: display managers

[Brian May <bam@debian.org>]

>>>>> "Branden" == Branden Robinson <branden@ecn.purdue.edu> writes:

    Branden> I am closing this bug because the task-x-window-system
    Branden> package is for novice users who want what is described in
    Branden> its package description.  (Note that
    Branden> task-x-window-system-core does what an older version of
    Branden> task-x-window-system does.)

I have removed the bug number from this task, as I have raised
issues which don't directly affect the bug.

    Branden> I suggest that the other display managers be made part of
    Branden> different tasks.

Ok, so anotherwords you think a task-gnome-* (task-gnome-desktop?)
should depend on gdm. That sounds like a good idea...

This would mean that task-x-window-system and task-gnome-* conflict
(as xdm conflicts with gdm). apt-get can handle this fine, however,
last I tried tasksel, when two task-* conflicted with each other, it
just aborted and forced the user to reselect tasks again. I think
tasksel needs to be able to cope better with conflicting tasks (but
maybe this has already been fixed?). Perhaps it could be possible to
have task-gnome-* directly conflict with task-x-window-system, and
tasksel would be able to tell the user the tasks conflict without
running apt-get.

    Branden> gdm can be made part of some kind of gnome task.  kdm can
    Branden> be made part of some kind of KDE task -- assuming we can
    Branden> ship a meaningful KDE task.  wdm can be made part of some
    Branden> Window Maker or otherwise NeXTish task.

    Branden> Each of the above tasks can and should depend on
    Branden> task-x-window-system-core to bring in the essential
    Branden> pieces of the X Window System.  The -core task does *NOT*
    Branden> contain xdm.

Agreed.

    Branden> I furthermore agree with the sentiment, expressed in a
    Branden> recent mail to this list, that the task packages are made
    Branden> deliberately simplistic for the sake of newcomers to
    Branden> Debian, and/or people who might be daunted by the number
    Branden> of packages we provide.  They are not really designed for
    Branden> experienced users or package maintainers.  Let us not
    Branden> migrate the complex web of conflicts/replaces/provides in
    Branden> our real packages to the tasks, please.  They are a
    Branden> limited tool for a limited purpose.

In that case, what Debian urgently needs is some way to easily
maintain a large number of packages, for experienced users. Such a
method would have to abstract the administrator from having to deal
with individual packages (eg like task-* packages do), but would have
to allow the system administrator to override the defaults (unlike
task-* packages). Unlike task-* packages, it should maintain
consistency across upgrades, remove packages that are obsolute and/or
no longer needed (eg if mh is installed, suggest replacing it with nmh
instead).

Of course, the system administrator needs to be able to override any
decisions it makes.

The again, some of what I said might be difficult (eg how would it
know that mh is obsolute, and should be replaced by nmh instead), but
I think it would be worth it.

    Branden> Finally, yes, there may be a better solution.  The real
    Branden> problem is that we don't have a central repository for VC
    Branden> allocation data.  If we do, then we can solve this
    Branden> problem, but it will probably mean /etc/inittab,
    Branden> /etc/X11/xdm/Xservers, and whatever the other display
    Branden> managers use to decide when to launch X servers will lose
    Branden> their conffile status and will have to be autogenerated.

I dont know how you could solve the problem by altering /etc/inittab.

You could for instance, have an entry, say

7:23:respawn:X --query localhost tty7

however, that is inefficient, as communications to the Xserver are now
done by TCP/IP.

Perhaps you could have gdm start a proxy server instead of the real
server, that passes the correct parameters (eg magic cookies) to an
inittab based server, which then loads the real X server. Sounds
rather complicated, though, to me.

I agree, it would be good if this problem was fixed, however, I don't
know how you would fix it.
-- 
Brian May <bam@debian.org>