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