the graphical drakx tools test if they are in a graphical session trough
a method (check_for_x_server) contained in "drakxtools-backend" rpm package, which in turn calls a method (xf86main::main::Xtest) contained in "libdrakx-kbd-mouse-x11"

if, for whatever reason, the version of libdrakx-kbd-mouse-x11 is no longer n sync with drakxtools-backend (for example, an aborted in the middle update); then the whole set of drakx tools will think they are in console mode as the above test will fail.
That is particularly important for rpmdrake, which doesn't has a text mode version.

The bug has already popped in the past: #6362
note it is not related to hostname; I can launch any other graphical program (eg: launching xeyes as root works; launching rpmdrake doesn't)

Steps to Reproduce:
1. install or upgrade to cauldron (mga4)
2. install force libdrakx-kbd-mouse-x11 from mga3 (to simulate an update that went wrong): rpm -Uv libdrakx-kbd-mouse-x11-*mga3*rpm
3. try to run rpmdrake

Googling a bit shows that this problem has already happened to some people.

a possible solution would be to add "Requires: libdrakx-kbd-mouse-x11 >= someversion" to "drakxtools-backend" rpm package (but what triggers that incompatibility? which version to set?)

or maybe do a more lax test to see if the graphical display is available shouldn't testing on $DISPLAY be enough? or maybe try to display a (possibly invisible) small gtk window?

For configuration of Xserver a more complex test may make sense; but for standard tools, and in particular for rpmdrake, a simpler test will allow people struck with an incomplete update to resume it; without being completly lost with a non working rpmdrake, just because it thinks there is no X.

maybe adding "libdrakx-kbd-mouse-x11" as a (possibly unversioned) requires to "drakxtools-backend" would make them more closelty tied, and have better chances to be installed/updated together?



Reproducible: 

Steps to Reproduce: