Don today in #xmonad linked http://braindump.dk/tech/2009/05/01/xmonad-upgrade/ The problem seems to be that the custom xmonad binary was not being recompiled even when XMonad was upgraded/reinstalled. Fortunately, I had seen a Yi technique which asked Cabal for the installed binary's patch; then it could get the last-modified times of the installed binary & the custom binary, and force a recompile if the former was newer than the latter. I coded this up for xmonad-core, but whenever I try it out, I get link errors. This is not the first time I've seen such errors, so I do not know whether my patch is flawed or my setup. If anyone wants to try it themselves and perhaps fix it, I'm attaching it. The changes: hunk ./XMonad/Core.hs 55 +import System.FilePath.Posix (()) hunk ./XMonad/Core.hs 60 +import Paths_xmonad (getBinDir) + hunk ./XMonad/Core.hs 399 +-- * the installed xmonad executable is more recent than the custom xmonad +-- hunk ./XMonad/Core.hs 408 --- hunk ./XMonad/Core.hs 411 + cabalBinDir <- getBinDir + let cabalBin = cabalBinDir "xmonad" + cabalBinT <- getModTime cabalBin hunk ./XMonad/Core.hs 421 - if (force || srcT > binT) + if (force || srcT > binT || cabalBinT > binT) hunk ./XMonad/Main.hsc 43 + + hunk ./XMonad/Main.hsc 124 - + -- have recompile check for a stale custom binary + recompile False hunk ./xmonad.cabal 44 - build-depends: base < 4 && >=3, containers, directory, process + build-depends: base < 4 && >=3, containers, directory, process, filepath -- gwern