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:
pgpWdICfgLRep.pgp
Description: PGP signature