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

Re: display managers



On Sat, Jan 22, 2000 at 12:46:28PM +1100, Brian May wrote:
> 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.

Hmm.  Like I said elsewhere, I'd rather not see task packages conflicting
with each other if we can help it.  But I know next to nothing about
tasksel at the moment.  I guess we need to get Randolph Chung or Joey Hess
in on this conversation.  Guys?  :)

> 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).

Uh, isn't this what apt does?  We get rave reviews for it.  All we need now
is a good point-and-drool front end.

I don't think there is ultimately a good way to do package management
without dealing with packages.  :)  What's the expression?  "Things should
made as simple as possible, but no simpler."  :)

>     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.

Sorry, maybe I wasn't clear.

I meant we'd have a file, /etc/vc.conf, or something, and a script,
update-vc-alloc, or something, which would auto-generate /etc/inittab and
/etc/X11/{g,k,w,x}dm/Xservers.

> 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.

That's a nifty trick and I've done it before, but also unimplementable now
because TCP listening has been turned off by default in xdm due to security
concerns.  The other 3 display managers should probably have it switched
off as well (not an issue for the ones that can't even speak XDMCP).

> 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.

Yes, something along those lines occurred to me as well a while back and I
rejected it for the same reason.

-- 
G. Branden Robinson            |       If you have the slightest bit of
Debian GNU/Linux               |       intellectual integrity you cannot
branden@ecn.purdue.edu         |       support the government.
roger.ecn.purdue.edu/~branden/ |       -- anonymous

Attachment: pgpMW0gOrZwh4.pgp
Description: PGP signature


Reply to: