On Mon, Apr 26, 1999 at 06:26:36PM +0200, Ruud de Rooij wrote:
> Johnie Ingram <johnie@netgod.net> writes:
>
> > Discovered earlier today on IRC: The kdebase package apparently
> > depends on 'xdm', which the new X packages react badly to. You can't
> > suppress the graphical startup without removing KDE.
>
> Then KDE needs to split off KDM from kdebase, just as XDM was split
> off from xbase.
I don't know that splitting kdm from kdebase is the issue so much as the
fact that the packaging of kdebase seems to be completely unaware of the
Great X Reorganization and all the consequences that had on xdm and its
conffiles.
X display managers no longer have to fight with the fact that xdm is always
around. On Debian systems, xdm itself need only be there if it is wanted.
The KDE packages need to not mess with /etc/X11/config anymore. That file
is deprecated and should not be created by any package; if anything uses
it, it should do so only by falling back upon it.
Personally, I want /etc/X11/config to go away and never come back.
Individual sysadmins can of course have such a file, just as they can have
/etc/this_is_my_box_and_I_can_put_crap_in_etc_if_I_want_to. I just don't
want it given preferential treatment in packages anymore.
xdm was split off (and xbase all but destroyed) for good reasons.
Historically, the KDE packages have tried to overwrite some of X's
conffiles, which is just obscenely bad behavior on KDE's part. Now that
the X packages have been better modularized, KDE can get its wish and be
the only dog in the junkyard without resorting to such tactics.
The reason I exploded on IRC was because I we seem to have a lot of newbies
coming in and griping about xdm automatically starting on boot. I knew
that xdm wasn't installed by default anymore (unless, I guess, you pick the
stickiest, GUI-est installation profile in dbootstrap), so I was wondering
how the heck so many people who weren't upgrading from hamm were getting
xdm on their boxes when they didn't want it. Turns out KDE is dragging xdm
in for no good reason. (Even though KDE is nowhere to be found on any
official Debian archive, newbies seem to be remarkably resourceful and
capable when it comes to finding .debs of it :).) I continue to believe
that the default configuration for xdm (autostart on boot and manage :0 on
vt 7) is the most sensible one, being the most popular configuration. The
issue is that people who don't want xdm AT ALL are seeing it installed;
that's a package dependency problem and the bug is in the packages that
senselessly depend on xdm.
Anybody who wants to render kdm sane again can follow the examples in the
xdm or wdm packages. Put the config files in /etc/X11/kwm (or
/etc/X11/{kde,KDE}/kwm or whatever is canonical for KDE stuff, drop the
init script in /etc/init.d, update-rc.d it and you're off to the races.
There is, unfortunately, the potential scenario of multiple display
managers being installed, and all trying to manage :0. I'm open to
suggestions about how to resolve this. I don't think alternatives are the
way to go because there's no reason you can't have xdm managing :0, wdm
managing :1, and kdm managing :2, for instance.
Thoughts?
By the way, I witnessed first-hand two examples of xdm *NOT* going into the
endless-respawn-cycle-of-death when it had problems today. In the first
scenario, the mouse was unplugged. The server cycled and died four times,
xdm gave up and came back to the login prompt on vt1 no worse for the wear
after only a few seconds. The second time, xfs was hung in limbo and
couldn't serve up the "fixed" font so the server died while trying to bring
up the xdm login widget. Same thing, cycled four times and died.
Informative messages were placed in /var/log/xdm.log. So I think we can
scatter the ashes on that long-standing bug. We owe a debt of thanks to
Marcelo Magallon for fixing that one.
Anyway, I finished the X 3.3.3.1-1 fonts and uploaded them (see
debian-devel-changes). Now I just have to decide how many patches I'm
going to put on the xfree86-1 3.3.3.1-1 source package before I release it.
(And yes, you kooky nags on IRC, I'll enable the GLX stub extension.)
Apparently my test builds (and netgod's glibc 2.0 versions) have been
working fine for people, so this part shouldn't take too long. 3.3.3.1-1
is going to be stuck in Incoming for a while until the archive maintainers
deal with the new source packaging. See the XSF page,
http://master.debian.org/~branden/xsf.html for more info. Due to their
likely delay in being dinstalled, I'll probably stick the .debs (and source
packages, so netgod can build them for glibc 2.0 :) ) up on samosa and link
to them from the XSF page on master.
--
G. Branden Robinson | Human beings rarely imagine a god that
Debian GNU/Linux | behaves any better than a spoiled child.
branden@ecn.purdue.edu | -- Robert Heinlein
cartoon.ecn.purdue.edu/~branden/ |
Attachment:
pgpUhN0baBv44.pgp
Description: PGP signature