On Wed, May 31, 2000 at 07:23:12PM -0400, Thomas Bushnell, BSG wrote: > Branden Robinson <branden@ecn.purdue.edu> writes: [...] > I had no objection to fetching the bug numbers; I probably should have > included them in my original message since I had them right at hand > and it would save everyone time. Please don't get upset on my behalf; > it was no problem. I wasn't upset on your behalf, I was just a little amazed at Ian. But I'll reserve analysis of such things for my correspondence with him directly. > Please try and separate these two issues: > > 1: The packages conflict and it would be nicer for everyone if they > didn't; > 2: The packages conflict and therefore they can't all be in Optional. > > I'm not concerned with fixing (1) right now. I might well put time > into it myself to see if I can think of a good solution and mail in > patches; it's certainly not my style to demand that already overworked > package maintainers do things just to make me happy. They do a good > job and anything that sounds like the contrary is only my failure to > take enough time to word complex email messages correctly. Well, seeing as the second release cycle has already started, we do have a *little* time to try and figure something out. In fact, I'd like to invite Ryan (gdm maintainer) and Dan (wdm maintainer) to participate in some brainstorming on the debian-x mailing lists, whose charter clearly contains issues like this, to see if we can't in fact cook up a solution that will permit all the display managers to live together with Optional priority. The problem, just so everyone knows, is that the display managers don't know about which, if any, virtual consoles are in use. We had bugs open literally for years against xdm because of this; it would get in fights with getty, each trying to open and write to the same VC. This usually causes hard console lockups. If the user doesn't have a way to remotely access his machine, he must hard reset or power cycle it. Very bad. The above problem has been worked around by telling display managers specifically to use vt7, since the default Debian /etc/inittab allocated getty's on vt's 1 through 6. As you can see, the problem of console lockups is not confined to display managers. I can think of a few possible approaches, each successively broader in scope, but possibly also correspondigly dangerous to implement during freeze. 1) Put a crude lockfile mechanism into each display manager so that they watch out for each other. I brainstormed about this with Ryan today in IRC. Basically, we'd modify the source of each DM to touch a file in /var/run corresponding to the VC opened for a local X session. This file would be removed when the DM stopped using that VC. Before opening it, of course, it would check for a lock file corresponding to the VT it was about to open. Advantages: relatively easy to implement Disadvantages: specific VT's will HAVE to be used in the configuration files of the display managers; xdm does this already -- I don't know about the others. You can't check for a lockfile before you know what VC you want. Also, this is a "cooperative" system that only works for programs that know about it. You could still deliberate induce a lockup with getty or openvt. 2) Write a script to manage the /etc/inittab file, and have the display managers stick themselves in it via this script in their postinst script. Advantages: familiar Debian approach to conffiles that need to be managed by multiple packages; also pretty easy to implement, probably even easier than 1); permits centralized management of VC's through a familiar interface (inittab), with fewer surprises for admins Disadvantages: will need involvement of sysvinit maintainer; still possible to cause a lockup with openvt or usage of getty from the command line 3) Change the kernel, C library, and/or lots and lots of apps to use good old-fashioned file locking on VC device files. Advantages: an almost foolproof way to prevent the console lockup problem Disadvantages: possibly a lot of code to change, and a distinct diversion from the norm of other Linux distributions > I'm trying to fix (2); it's a very important problem, and it's pretty > easily fixed. When we have figured out a good solution to (1), then > we can move all the packages into Optional, but until then, they just > can't all be there. Richard Braakman disagrees, and says that we have always shipped Debian with a not-fully-installable Optional priority. Why don't we find out if attacking this display manager problem really is going to solve issue 2) generally? > To summarize: > > Number (1) is a wishlist item. I wouldn't trivialize it to that degree because of the consequences when you lock up the console of a standalone box. > Number (2) is a real bug (a clear violation of an important policy > provision, and easily fixed) and I believe it is release critical, for > the user-confusion-at-install-time issue I have already outlined. See above. -- G. Branden Robinson | Debian GNU/Linux | The software said it required Windows branden@ecn.purdue.edu | 3.1 or better, so I installed Linux. roger.ecn.purdue.edu/~branden/ |
Attachment:
pgpCGE640tb_d.pgp
Description: PGP signature