On Wed, Sep 04, 2002 at 06:17:05AM -0400, John D. Hendrickson wrote: > I've found a few problems with the X startups: which often don't really > start X :) The maintainers of some display managers have found it prudent to ignore the mechanisms I have put in place to ensure a consistent experience regardless of whether the user starts his X session with startx, xdm, gdm, etc. > When Gnome doesn't load it often leaves no log messages or console > messages as to why: you'd have to get the source or just guess. $HOME/.xsession-errors If it doesn't leave them there, it's buggy. > GDM BUG: GDM does not really login users correctly: > > --> GDM logs in the user without a login ENVIRONMENT <-- > > --> XDM logs in the user WITH a POSIX login ENVIRONMENT <-- > (xdm can launch gnome easily) > > After much work figuring out why my login ENV wasn't being > loaded, I narrowed it down to GDM (because everything GNOME > works until GDM enters the picture). I wrote the author > and of course got no reply. > > (You might not notice this unless you use a POSIX compliant > login environment that sets environment variable when. A > workaround for bash is below.) In my opinion, gdm's session type should default to using /etc/X11/Xsession. The maintainer disagrees, it would seem. Not much I can do about that. File a bug on gdm. > DEBIAN BUG: Xsession > > Xsession breaks the Xfree86 starup rules - with the meantion that > those 'old startups' didn't handle multiple startups. That is > is just plain wrong. I don't even understand what you're saying here. What rules? All the rules with which I am familiar are documented in: xdm(1) startx(1) xinit(1) Xsession(5) > However, Xsession ISN'T IN THE LOOP for Gnome startup. See above. > So, if its not 'IN THE LOOP' for starting the big few desktops, why > does it need to ignore Xfree86 configs which work with xinit, xdm, > startx (had Xsession not been there to misconfigure things ??) Xsession doesn't misconfigure anything. > That is: why does Xsession need to rename the startup files and > call them in a different order -- but add nothing new to the > startup process ?? Xsession doesn't rename anything. What are you talking about? What gets called in a different order, and different from what? Perhaps you'd prefer the Red Hat way where they have you using .xinitrc for startx and .Xsession for xdm, and still use the X11R1 "standard" .Xdefaults file instead of .Xresources? Hint: .Xdefaults was obsolete even in 1993. > Certainly, a 'run-parts' could be in the system 'xinit'. So > that is not an answer. It's more straightforward not to fork upstream xinit in this fashion. That would be "breaking the rules", and "just plain wrong". By the way, xinit is an ELF executable, not a shell script. > Xinit, startx, xdm, ... have allways been compatible with > multiple window managers. That's nothing new in any system. They still are. > However, Xsession breaks the POSIX starup rule that allows the > user to control their own starup in their home directory(s). When and where did POSIX standardize X session launch procedures? Chapter and verse, please. man Xsession In Debian, it's easy to tell startx and (in principle) any display manager to cut to the chase and do only what you want: It's called $HOME/.xsession Any display manager that respects /etc/X11/Xsession by default will respect this as well. Perhaps you need to be filing a bug against gdm. > Of course the old configs *were* carefully organized to allow > system defaults AND user control as well - because it is the > unix way to allow the user to run non-root software they have > permission to run - they way they need to run it, right? It's the Debian way, too, provided one reads the manpages and doesn't confuse the way Red Hat or Solaris does things with "POSIX". Please direct further inquiries to debian-user@lists.debian.org. -- G. Branden Robinson | Suffer before God and ye shall be Debian GNU/Linux | redeemed. God loves us, so He branden@debian.org | makes us suffer Christianity. http://people.debian.org/~branden/ | -- Aaron Dunsmore
Attachment:
pgpaIQpN7DEdg.pgp
Description: PGP signature