

Re: problems with latest x version in incoming

> I´m afraid there are a lot of them. In fact installing them broke my system
> completely since I need X. Here's what I still remember:

> 1) xdm is started regardless whether it is confugured to do so. I have
> no-start-xdm in my config file but still it starts up.

This is a feature, not a bug.  If xdm is installed, the daemon will attempt
to start in the postinst, just like any other package that ships a daemon.
Before starting, however, xdm uses the parse-xf86config script (in the
xserver-common package) to attempt to determine if the XF86Config file is
legal.  If it isn't, xdm will not start.

(no-)start-xdm was always, IMO, a crude hack to keep a daemon from running
that some people might not want to use.  I think a better solution is to
separate out the daemons so that only people interested in them have to
worry about them -- so that's what I did.  xdm and xfs are now distinct

See /usr/doc/xdm/README.Debian, xdm.options(5), and /etc/init.d/xdm for
more information.

> 2) some preinsts call getreal() but the function is named readlink()

Thinko.  Fix will be in the next release.

> 3) The server no longer is setud root.  Thus it refuses to come up at all.
> 4) startx only comes up under root (some authority problem).

I'm now using suidregister to make /usr/bin/X11/X (which is Debian's X
server wrapper) setuid root -- it ships with plain old mode 755.
xserver-common (which contains the wrapper) was one of the files with the
"getreal" problem, so the script bombed out before suidregister was called.
With the fixing of 2) above this should no longer be a problem.

> 5) xkbcomp refuses to work (some incorrect paths).

I think I know what's up with this but it's going to take a little
research.  This should be a non-fatal problem.  If the X server refuses to
start, something else is wrong.

> 6) Some more problems in pre/post-insts like incorrect test values or
> incorrect parameters to start-stop-daemon.

Fixed in the next release; Joseph Carter sent me his dpkg output and
pinpointed these problems.

> 7) The font packages have been renamed but don't provide the old names thus
> breaking some dependecies, most notably the Gimp.

Packages that depend explicitly on some X font packages should switch to
the new names.  Also, it's often a bad idea to have a dependency on an X
font package, as the same fonts a package requires may be retrieved through
an X font server.  So "Recommends:" should probably be as strong a
dependency as there is on the xfonts-* packages.  When I next see Che_Fox
in IRC I'll talk to him about the Gimp, and see if my reasoning applies in
that case.

> Since I take it this isn't meant to go into frozen it's not that much a
> problem though.

I did try to warn people.  Now that the freeze has apparently been
pushed back yet again, I regret the premature release, but I didn't know
about it at the time.

Sorry for the problems.  I'm fixing them as soon as I become aware of them.

Debian GNU/Linux                 |   screaming mob pounding on a greasy spot
branden@ecn.purdue.edu           |   on the pavement, where used to lie the
cartoon.ecn.purdue.edu/~branden/ |   carcass of a dead horse.

Attachment: pgpvqSoIkFLuA.pgp
Description: PGP signature

Reply to: